Observability for AI Systems: Strengthening visibility for proactive risk detection

Adoption of Generative AI (GenAI) and agentic AI has accelerated from experimentation into real enterprise deployments. What began with copilots and chat interfaces has quickly evolved into powerful business systems that autonomously interact with sensitive data, call external APIs, connect to consequential tools, initiate workflows, and collaborate with other agents across enterprise environments. As these AI systems become core infrastructure, establishing clear, continuous visibility into how these systems behave in production can help teams detect risk, validate policy adherence, and maintain operational control.

Observability is one of the foundational security and governance requirements for AI systems operating in production. Yet many organizations don’t understand the critical importance of observability for AI systems or how to implement effective AI observability. That mismatch creates potential blind spots at precisely the moment when visibility matters most.

In February, Microsoft Corporate Vice President and Deputy Chief Information Security Officer, Yonatan Zunger, blogged about expanding Microsoft’s Secure Development Lifecycle (SDL) to address AI-specific security concerns. Today, we continue the discussion with a deep dive into observability as a necessity for the secure development of GenAI and agentic AI systems.

For additional context, read the Secure Agentic AI for Your Frontier Transformation blog that covers how to manage agent sprawl, strengthen identity controls, and improve governance across your tenant.

Observability for AI systems

In traditional software, client apps make structured API calls and backend services execute predefined logic. Because code paths follow deterministic flows, traditional observability tools can surface straightforward metrics like latency, errors, and throughput to track software performance in production.

GenAI and agentic AI systems complicate this model. AI systems are probabilistic by design and make complex decisions about what to do next as they run. This makes relying on predictable finite sets of success and failure modes much more difficult. We need to evolve the types of signals and telemetry collected so that we can accurately understand and govern what is happening in an AI system.

Consider this scenario: an email agent asks a research agent to look up something on the web. The research agent fetches a page containing hidden instructions and passes the poisoned content back to the email agent as trusted input. The email agent, now operating under attacker influence, forwards sensitive documents to unauthorized recipients, resulting in data exfiltration.

In this example, traditional health metrics stay green: no failures, no errors, no alerts. The system is working exactly as designed… except a boundary between untrusted external content and trusted agent context has been compromised.

This illustrates how AI systems require a unique approach to observability. Without insights into how context was assembled at each step—what was retrieved, how it impacted model behavior, and where it propagated across agents—there is no way to detect the compromise or reconstruct what occurred.

Traditional monitoring, built around uptime, latency, and error rates, can miss the root cause here and provide limited signal for attribution or reconstruction in AI-related scenarios. This is an example of one of the new categories of risk that the SDL must now account for, and it is why Microsoft has incorporated enhanced AI observability practices within our secure development practices.

Traditional observability versus AI observability

Observability of AI systems means the ability to monitor, understand, and troubleshoot what an AI system is doing, end-to-end, from development and evaluation to deployment and operation. Traditional services treat inputs as bounded and schema-defined. In AI systems, input is assembled context. This includes natural language instructions plus whatever the system pulls in and acts on, such as system and developer instructions, conversation history, outputs returned from tools, and retrieved content (web pages, emails, documents, tickets).

For AI observability, context is key: capture which input components were assembled for each run, including source provenance and trust classification, along with the resulting system outputs.

Traditional observability is often optimized for request-level correlation, where a single request maps cleanly to a single outcome, with correlation captured inside one trace. In AI systems, dangerous failures can unfold across many turns. Each step looks harmless until the conversation ramps into disallowed output, as we’ve seen in multi-turn jailbreaks like Crescendo.

For AI observability, best practices call for propagating a stable conversation identifier across turns, preserving trace context end-to-end, so outcomes can be understood within the full conversational narrative rather than in isolation. This is “agent lifecycle-level correlation,” where the span of correlation should be the same as the span of persistent memory or state within the system.

Defining AI system observability

Traditional observability is built on logs, metrics, and traces. This model works well for conventional software because it’s optimized around deterministic, quantifiable infrastructure and service behavior such as availability, latency, throughput, and discrete errors.

AI systems aren’t deterministic. They evaluate natural language inputs and return probabilistic results that can differ subtly (or significantly) from execution to execution. Logs, metrics, and traces still apply here, but what gets captured within them is different. Observability for AI systems updates traditional observability to capture AI-native signals.

Logs, metrics, and traces indicate what happened in the AI system at runtime.

• Logs capture data about the interaction: request identity context, timestamp, user prompts and model responses, which agents or tools were invoked, which data sources were consulted, and so on. This is the core information that tells you what happened. User prompts and model responses are often the earliest signal of novel attacks before signatures exist, and are essential for identifying multi-turn escalation, verifying whether attacks changed system behavior, adjudicating safety detections, and reconstructing attack paths. User-prompt and model-response logs can reveal the exact moment an AI agent stops following user intent and starts obeying attacker-authored instructions from retrieved content.
• Metrics measure traditional performance details like latency, response times, and errors as well as AI-specific information such as token usage, agent turns, and retrieval volume. This information can reveal issues such as unauthorized usage or behavior changes due to model updates.
• Traces capture the end-to-end journey of a request as an ordered sequence of execution events, from the initial prompt through response generation. Without traces, debugging an agent failure means guessing which step went wrong.

AI observability also incorporates two new core components: evaluation and governance.

• Evaluation measures response quality, assesses whether outputs are grounded in source material, and evaluates whether agents use tools correctly. Evaluation gives teams measurable signals to help understand agent reliability, instruction alignment, and operational risk over time.
• Governance is the ability to measure, verify, and enforce acceptable system behavior using observable evidence. Governance uses telemetry and control plane mechanisms to ensure that the system supports policy enforcement, auditability, and accountability.

These key components of observability give teams improved oversight of AI systems, helping them ship with greater confidence, troubleshoot faster, and tune quality and cost over time.  

Operationalizing AI observability through the SDL

The SDL provides a formal mechanism by which technology leaders and product teams can operationalize observability. The following five steps can help teams implement observability in their AI development workflows.

1. Incorporate AI observability into your secure development standards. Observability standards for GenAI and agentic AI systems should be codified requirements within your development lifecycle; not discretionary practices left to individual teams.
2. Instrument from the start of development. Build AI-native telemetry into your system at design time, not after release. Aligning with industry conventions for logging and tracing, such as OpenTelemetry (OTel) and its GenAI semantic conventions, can improve consistency and interoperability across frameworks. For implementation in agentic systems, use platform-native capabilities such as Microsoft Foundry agent tracing (in preview) for runtime trace diagnostics in Foundry projects. For Microsoft Agent 365 integrations, use the OTel-based Microsoft Agent 365 Observability SDK (in Frontier preview) to emit telemetry into Agent 365 governance workflows.
3. Capture the full context. Log user prompts and model responses, retrieval provenance, what tools were invoked, what arguments were passed, and what permissions were in effect. This detail can help security teams distinguish a model error from an exploited trust boundary and enables end-to-end forensic reconstruction. What to capture and retain should be governed by clear data contracts that balance forensic needs against privacy, data residency, retention requirements, and compliance with legal and regulatory obligations, with access controls and encryption aligned to enterprise policy and risk assessments.
4. Establish behavioral baselines and alert on deviation. Capture normal patterns of agent activity—tool call frequencies, retrieval volumes, token consumption, evaluation score distributions—through Azure Monitor and Application Insights or similar services. Alert on meaningful departures from those baselines rather than relying solely on static error thresholds.
5. Manage enterprise AI agents. Observability alone cannot answer every question. Technology leaders need to know how many AI agents are running, whether those agents are secure, and whether compliance and policy enforcement are consistent. Observability, when coupled with unified governance, can support improved operational control. Microsoft Foundry Control Plane, for example, consolidates inventory, observability, compliance with organization-defined AI guardrail policies, and security into one role-aware interface; Microsoft Agent 365 (in Frontier preview) provides tenant-level governance in the Microsoft 365 admin plane.

To learn more about how Microsoft can help you manage agent sprawl, strengthen identity controls, and improve governance across your tenant, read the Secure Agentic AI for Your Frontier Transformation blog.

Benefits for security teams

Making enterprise AI systems observable transforms opaque model behavior into actionable security signals, strengthening both proactive risk detection and reactive incident investigation.

When embedded in the SDL, observability becomes an engineering control. Teams define data contracts early, instrument during design and build, and verify before release that observability is sufficient for detection and incident response. Security testing can then validate that key scenarios such as indirect prompt injection or tool-mediated data exfiltration are surfaced by runtime protections and that logs and traces enable end-to-end forensic reconstruction of event paths, impact, and control decisions.  

Many organizations already deploy inference-time protections, such as Microsoft Foundry guardrails and controls. Observability complements these protections, enabling fast incident reconstruction, clear impact analysis, and measurable improvement over time. Security teams can then evaluate how systems behave in production and whether controls are working as intended.

Adapting traditional SDL and monitoring practices for non-deterministic systems doesn’t mean reinventing the wheel. In most cases, well-known instrumentation practices can be simply expanded to capture AI-specific signals, establish behavioral baselines, and test for detectability. Standards and platforms such as OpenTelemetry and Azure Monitor can support this shift.

AI observability should be a release requirement. If you cannot reconstruct an agent run or detect trust-boundary violations from logs and traces, the system may not be ready for production.

The post Observability for AI Systems: Strengthening visibility for proactive risk detection appeared first on Microsoft Security Blog.

from Microsoft Security Blog https://ift.tt/LFtTYu7
via IFTTT

9 Critical IP KVM Flaws Enable Unauthenticated Root Access Across Four Vendors

Cybersecurity researchers have warned about the risks posed by low-cost IP KVM (Keyboard, Video, Mouse over Internet Protocol) devices, which can grant attackers extensive control over compromised hosts.

The nine vulnerabilities, discovered by Eclypsium, span four different products from GL-iNet Comet RM-1, Angeet/Yeeso ES3 KVM, Sipeed NanoKVM, and JetKVM. The most severe of them allow unauthenticated actors to gain root access or run malicious code.

"The common themes are damning: missing firmware signature validation, no brute-force protection, broken access controls, and exposed debug interfaces," researchers Paul Asadoorian and Reynaldo Vasquez Garcia said in an analysis.

With IP KVM devices enabling remote access to the target machine's keyboard, video output, and mouse input at the BIOS/UEFI level, successful exploitation of vulnerabilities in these products can expose systems to potential takeover risks, undermining security controls put in place. The list of shortcomings is as follows -

• CVE-2026-32290 (CVSS score: 4.2) - An insufficient verification of firmware authenticity in GL-iNet Comet KVM (Fix being planned)
• CVE-2026-32291 (CVSS score: 7.6) - A Universal Asynchronous Receiver-Transmitter (UART) root access vulnerability in GL-iNet Comet KVM (Fix being planned)
• CVE-2026-32292 (CVSS score: 5.3) - An insufficient brute-force protection vulnerability in GL-iNet Comet KVM (Fixed in version 1.8.1 BETA)
• CVE-2026-32293 (CVSS score: 3.1) - An insecure initial provisioning via unauthenticated cloud connection vulnerability in GL-iNet Comet KVM (Fixed in version 1.8.1 BETA)
• CVE-2026-32294 (CVSS score: 6.7) - An insufficient update verification vulnerability in JetKVM (Fixed in version 0.5.4)
• CVE-2026-32295 (CVSS score: 7.3) - An insufficient rate limiting vulnerability in JetKVM (Fixed in version 0.5.4)
• CVE-2026-32296 (CVSS score: 5.4) - A configuration endpoint exposure vulnerability in Sipeed NanoKVM (Fixed in NanoKVM version 2.3.1 and NanoKVM Pro version 1.2.4)
• CVE-2026-32297 (CVSS score: 9.8) - A missing authentication for a critical function vulnerability in Angeet ES3 KVM leading to arbitrary code execution (No fix available)
• CVE-2026-32298 (CVSS score: 8.8) - An operating system command injection vulnerability in Angeet ES3 KVM leading to arbitrary command execution (No fix available)

"These are not exotic zero-days requiring months of reverse engineering," the researchers noted. "These are fundamental security controls that any networked device should implement. Input validation. Authentication. Cryptographic verification. Rate limiting. We are looking at the same class of failures that plagued early IoT devices a decade ago, but now on a device class that provides the equivalent of physical access to everything it connects to."

An adversary can weaponize these issues to inject keystrokes, boot from removable media to bypass disk encryption or Secure Boot protections, circumvent lock screens and access systems, and, more importantly, remain undetected by security software installed at the operating system level.

This is not the first time vulnerabilities have been disclosed in IP KVM devices. In July 2025, Russian cybersecurity vendor Positive Technologies flagged five flaws in ATEN International switches (CVE-2025-3710, CVE-2025-3711, CVE-2025-3712, CVE-2025-3713, and CVE-2025-3714) that could pave the way for denial-of-service or remote code execution.

What's more, such IP KVM switches like PiKVM or TinyPilot have been put to use by North Korean IT workers residing in countries like China to remotely connect to company-issued laptops hosted on laptop farms.

As mitigations, it's recommended to enforce multi-factor authentication (MFA) where supported, isolate KVM devices on a dedicated management VLAN, restrict internet access, use tools like Shodan to check for external exposure, monitor for unexpected network traffic to/from the devices, and keep the firmware up-to-date.

"A compromised KVM is not like a compromised IoT device sitting on your network. It is a direct, silent channel to every machine it controls," Eclypsium said. "An attacker who compromises the KVM can hide tools and backdoors on the device itself, consistently re-infecting host systems even after remediation."

"Since some firmware updates lack signature verification on most of these devices, a supply-chain attacker could tamper with the firmware at distribution time and have it persist indefinitely."

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

Product Walkthrough: How Mesh CSMA Reveals and Breaks Attack Paths to Crown Jewels

Security teams today are not short on tools or data. They are overwhelmed by both. 

Yet within the terabytes of alerts, exposures, and misconfigurations – security teams still struggle to understand context: 

Q: Which exposures, misconfigurations, and vulnerabilities chain together to create viable attack paths to crown jewels?

Even the most mature security teams can’t answer that easily.

The problem isn't the tools. It's that the tools don’t talk to each other. 

This is precisely the problem Gartner's Cybersecurity Mesh Architecture (CSMA) framework was designed to solve – and it's what Mesh Security has operationalized with the world's first purpose-built CSMA platform.

In this article, we’ll walk through what CSMA is and how Mesh CSMA: 

• Discovers attack paths to crown jewels
• Prioritizes based on active threats 
• Eliminates attack paths systematically

What Is CSMA, and Why Does It Matter Now?

Before we dive into the platform, let’s clarify what CSMA is.

CSMA, as defined by Gartner, is a composable, distributed security layer that connects your existing stack, giving you the context unification of a platform atop your best-of-breed tools. With CSMA, risk can be understood holistically rather than in silos.

The Problem: Isolated Tools Miss the Attack Story

We've all seen findings like these sitting in separate dashboards:

• A developer has installed a legitimate-looking AI coding assistant from the VS Code Marketplace
• That extension has been flagged as potentially trojanized — but the alert sits in one tool, unconnected to anything else
• The developer's workstation has long session timeouts and no device isolation policy enforced
• The developer's credentials have broad access to a production AWS account
• That AWS account has direct, unrestricted access to a production RDS database storing customer PII

In isolation, each signal looks manageable: a marketplace policy flag here, a session timeout misconfiguration there. Security teams see them, log them, and deprioritize them. None of them look like P1s on their own.

But strung together, they tell a very different story: a clear, multi-hop attack path from a developer's workstation straight to your most sensitive customer data. No breach has occurred – but the path is open, viable, and waiting.

Layer in threat intelligence, and the risk becomes even harder to ignore: threat actors are actively targeting developer environments and supply chain entry points as their preferred foothold into production infrastructure. Did you chain your tools flagged separately? It maps almost exactly to their playbook.

Mesh Live Threat Exposure

This is a live threat exposure. Not a breach, but an exploitable path that exists in your environment right now, invisible because no single tool can see all of it at once.

That's exactly what Mesh CSMA was created to solve. By unifying context across your entire stack, Mesh surfaces these cross-domain attack paths before they're exploited – so your team can break the chain before an attacker ever walks it.

How Mesh CSMA Works

Mesh CSMA turns fragmented signals into meaningful, cross-domain threat stories. So security teams can focus on what matters. 

Here’s how Mesh works.

Step 1: Connect – Agentless, No Rip-and-Replace

Mesh begins by integrating with your existing stack: all tools, data lakes, and infrastructure. (What does Mesh integrate with? See 150+ integrations here. 

Mesh Integrations

Step 2: See – The Mesh Context Graph™

Next, Mesh automatically discovers your Crown Jewels: production databases, customer data repositories, financial systems, code signing infrastructure – and anchors the entire risk model around them. 

This is the core principle that makes Mesh different: risk is understood relative to what actually matters to the business, not relative to the loudest alerts.

From there, Mesh builds the Mesh Context Graph™ – a continuously updating, identity-centric graph of every entity in your environment: users, machines, workloads, services, data stores, and the relationships between them.

Unlike asset inventories, which tell you what exists, the Mesh Context Graph™ tells you how everything connects. It maps access paths, trust relationships, entitlement chains, and network exposure in a single unified model – all traced back to your Crown Jewels. 

Mesh Context Graph

Step 3: Assess – Viable Attack Path Discovery

This is where Mesh diverges from traditional exposure management tools.

CTEM platforms and vulnerability scanners surface CVEs and misconfigurations. But a CVSS 9.8 vulnerability on an isolated, internet-facing asset with no path to anything sensitive is a very different risk than a CVSS 5.5 misconfiguration on a service account that has direct access to your production database. Mesh understands the difference.

The platform correlates findings across domains – cloud posture misconfigurations, identity entitlement overreach, detection blind spots, unpatched vulnerabilities – and traces them forward against the Context Graph to determine which combinations create viable, multi-hop attack chains to Crown Jewels. Then, it prioritizes based on live threat intelligence.

The result: a ranked, actionable list of complete cross-domain attack paths, each showing:

• Entry point: how an attacker would gain initial access
• Pivot chain: each intermediate hop through the environment
• Target: which Crown Jewel is reachable
• Why it's viable: the specific misconfigurations, access paths, or detection gaps enabling it
• Threat context: whether known active threat actors are currently exploiting this 

Mesh Crown Jewel Exposures

With Mesh, you can click into each Live Threat Exposure and visualize the attack path, turning isolated signals into a meaningful risk remediation road map.

Mesh Attack Path Visualization

Step 4: Eliminate – Breaking the Chain

Surfacing attack paths is only half the value. Mesh closes them.

For each identified attack path, Mesh generates specific, prioritized remediation actions mapped to the existing tools already in your stack. Rather than generic guidance like "patch this CVE," Mesh tells you: revoke this specific role binding, enforce MFA on this service account, update this CSPM policy, isolate this workload.

Critically, Mesh orchestrates remediation across domains – a single attack path might require a fix in your CSPM tool, a change in your IGA platform, and a policy update in your ZTNA solution. Mesh coordinates those actions without forcing your team to manually context-switch between consoles.

Step 5: Defend – Continuous Validation and Detection Gap Coverage

Mesh doesn't stop at posture. It also continuously validates your detection layer – identifying blind spots where attack techniques would succeed but generate no alerts.

This closes the loop between prevention and detection. Security teams can see not only where attackers can go but where they would go undetected if they tried. Detection gaps are surfaced alongside posture gaps within the same unified risk model, enabling prioritization that reflects true business risk.

Mesh continuously re-evaluates the environment as infrastructure changes, new tools are onboarded, and threat intelligence updates. The attack path map is never a point-in-time snapshot – it's a live model.

Mesh Auto Investigation Timeline

What Makes This Different from SIEM, XDR, or CTEM?

SIEM and XDR detect threats after signals are generated. They rely on events that have already happened and require significant tuning to reduce false positives. They don't model attack paths proactively.

CTEM platforms prioritize vulnerabilities based on exploitability scores, but most operate within a single domain (cloud, endpoint, identity) and struggle to model how risks from different domains chain together.

Large platform vendors achieve context unification but at the cost of vendor lock-in and the forced replacement of specialized tools.

Mesh takes a different approach. Aligning precisely with what Gartner envisioned for CSMA, Mesh unifies context across all existing tools, data lakes, and infrastructure, enabling continuous exposure elimination without requiring you to rip anything out.

Who Is Mesh Built For?

Mesh CSMA is built for security teams that have already invested in best-of-breed tools and are now dealing with the consequences of fragmented security:

• Dozens of dashboards, zero context
• Disjointed security data, generating noise instead of insights
• Manual correlation, connecting the dots between tools

The platform recently closed a $12M Series A led by Lobby Capital with participation from Bright Pixel Capital and S1 (SentinelOne) Ventures.

Your Next Move: Learn More About Mesh CSMA–

Security tools show isolated risks. Mesh shows attack paths to Crown Jewels – and eliminates them.

Want to see live threat exposures in your environment? Try Mesh free for 7 days.

Or register for the live webinar: Who Can Reach Your Crown Jewels? Attack Path Modeling with Mesh CSMA to see Mesh identify real attack paths live.

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

Transparent COM instrumentation for malware analysis

• COM automation is a core Windows technology that allows code to access external functionality through well-defined interfaces. It is similar to traditionally loading a DLL, but is class-based rather than function-based. Many advanced Windows capabilities are exposed through COM, such as Windows Management Instrumentation (WMI).  
• Scripting and late-bound COM calls operate through the IDispatch interface. This creates a key analysis point that many types of malware leverage when interacting with Windows components.This analysis point is quite complex and hard to safely instrumentate at scale. 
• In this article, Cisco Talos presents DispatchLogger, a new open-source tool that closes this gap by delivering high visibility into late-bound IDispatch COM object interactions via transparent proxy interception.  
• This blog describes the architecture, implementation challenges, and practical applications of comprehensive COM automation logging for malware analysis. This technique can be utilized on multiple types of malware.

Malware type	Binding type	Est. coverage
Windows Script Host	Always Late	100%
PowerShell COM	Always Late	100%
AutoIT	Always Late	100%
VBA Macros	Mostly Late	95%
VB6 Malware	Mixed	65%
.NET COM Interop	Mixed	60%
C++ Malware	Rarely Late (WMI)	10%

---

The challenge 

Modern script-based malware (e.g., VBScript, JScript, PowerShell) relies heavily on COM automation to perform malicious operations. Traditional dynamic analysis tools capture low-level API calls but miss the semantic meaning of high-level COM interactions. Consider this attack pattern:

Figure 1. Sample VBScript code to create a process with WMI as its parent.

Behavioral monitoring will detect process creation, but the analyst often loses critical context such as who launched the process. In this scenario WMI spawns new processes with wmic.exe or wmiprvse.exe as the parent.

Technical approach 

Interception strategy 

DispatchLogger starts with API hooking at the COM instantiation boundary. Every COM object creation in Windows flows through a small set of API functions. By intercepting these functions and returning transparent proxies deep visibility can be achieved without modifying malware behavior. 

The core API hooking targets are: 

1. CoCreateInstance: Primary COM object instantiation (CreateObject in scripts)  
2. CoGetClassObject: Class factory retrieval  
3. GetActiveObject: Attachment to running COM instances  
4. CoGetObject/MkParseDisplayName: Moniker-based binding (GetObject)  
5. CLSIDFromProgID: ProgID resolution tracking  

Why class factory hooking is essential 

Initial implementation attempts hooked only CoCreateInstance, filtering for direct IDispatch requests. However, testing revealed that most VBScript CreateObject calls were not being intercepted. 

To diagnose this a minimal ActiveX library was created with a MsgBox in Class_Initialize to freeze the process. The VBScript was launched, and a debugger attached to examine the call stack. The following code flow was revealed: 

Figure 2. Call stack showing how VBScript obtains a target IDispatch interface.

Disassembly of vbscript.dll!GetObjectFromProgID (see Figure 3) confirmed the pattern. VBScript's internal implementation requests IUnknown first, then queries for IDispatch afterward:

Figure 3. Disassembly of vbscript.dll!GetObjectFromProgID.

The key line is CreateInstance(NULL, IID_IUnknown, &ppunk). Here, VBScript explicitly requests IUnknown, not IDispatch. This occurs because VBScript needs to perform additional safety checks and interface validation before accessing the IDispatch interface. 

If we only wrap objects when IDispatch is directly requested in CoCreateInstance, we miss the majority of script instantiations. The solution is to also hook CoGetClassObject and wrap the returned IClassFactory: 

 Figure 4. Returning a Class Factory proxy from the CoGetClassObject API Hook.

The ClassFactoryProxy intercepts CreateInstance calls and handles both cases:

 Figure 5. Returning an IDispatch Proxy from ClassFactoryProxy::CreateInstance if possible.

This ensures coverage regardless of which interface the script engine initially requests.

Architecture 

Proxy implementation 

The DispatchProxy class implements IDispatch by forwarding all calls to the wrapped object while logging parameters, return values, and method names. If the function call returns another object, we test for IDispatch and automatically wrap it.

Figure 6. Simplified flow of IDispatch::Invoke hook. Full hook is around 300 loc.

The proxy is transparent, meaning it implements the same interface, maintains proper reference counting, and handles QueryInterface correctly. Malware cannot detect the proxy through standard COM mechanisms. 

Recursive object wrapping 

The key capability is automatic recursive wrapping. Every IDispatch object returned from a method call is automatically wrapped before being returned to the malware. This creates a fully instrumented object graph. 

Figure 7. Sample VBScript code detailing hooking capabilities.

Object relationships are tracked: 

1. GetObject("winmgmts:") triggers hook, returns wrapped WMI service object  
2. Calling .ExecQuery() goes through proxy, logs call with SQL parameter  
3. Returned query result object is wrapped automatically  
4. Enumerating with For Each retrieves wrapped IEnumVARIANT  
5. Each enumerated item is wrapped as it's fetched  
6. Calling .Terminate() on items logs through their respective proxies  

Enumerator interception 

VBScript/JScript For Each constructs use IEnumVARIANT for iteration. We proxy this interface to wrap objects as they're enumerated: 

Figure 8. Implementation of IEnumVariant.Next that wraps child objects in the IDispatch proxy.

Moniker support 

VBScript's GetObject() function uses monikers for binding to objects. We hook CoGetObject and MkParseDisplayName, then wrap returned moniker objects to intercept BindToObject() calls: 

Figure 9. Implementation of IMoniker.BindToObject that wraps the returned object with an IDispatch Proxy.

This ensures coverage of WMI access and other moniker-based object retrieval.

Implementation details 

Interface summary 

While standard API hooks can be implemented on a function-by-function basis, COM proxies require implementing all functions of a given interface. The table below details the interfaces and function counts that had to be replicated for this technique to operate.

Interface	Total Methods	Logged	Hooked/Wrapped	Passthrough
IDispatch	7	4	1	2
IEnumVARIANT	7	1	1	5
IClassFactory	5	2	1	2
IMoniker	26	1	1	24

During execution, a script may create dozens or even hundreds of distinct COM objects. For this reason, interface implementations must be class-based and maintain a one-to-one relationship between each proxy instance and the underlying COM object it represents. 

While generating this volume of boilerplate code by hand would be daunting, AI-assisted code generation significantly reduced the effort required to implement the complex interface scaffolding. 

The real trick with COM interface hooking is object discovery. The initial static API entry points are only the beginning of the mission. Each additional object encountered must be probed, wrapping them recursively to maintain logging.

Thread safety 

Multiple threads may create COM objects simultaneously. Proxy tracking uses a critical section to serialize access to the global proxy map:

Figure 10. Thread safety checks in the WrapDispatch function.

Reference counting 

Proper COM lifetime management is critical. The proxy maintains separate reference counts and forwards QueryInterface calls appropriately:

Figure 11. The IDispatch proxy maintains proper reference counts.

Output analysis 

When script code executes with DispatchLogger active, comprehensive logs are generated. Here are excerpts from an actual analysis session:

Object creation and factory interception:

[CLSIDFromProgID] 'Scripting.FileSystemObject' -> {0D43FE01-F093-11CF-8940-00A0C9054228} 
[CoGetClassObject] FileSystemObject ({0D43FE01-F093-11CF-8940-00A0C9054228}) Context=0x00000015 
[CoGetClassObject] Got IClassFactory for FileSystemObject – WRAPPING! 
[FACTORY] Created factory proxy for FileSystemObject 
[FACTORY] CreateInstance: FileSystemObject requesting Iunknown 
[FACTORY] CreateInstance SUCCESS: Object at 0x03AD42D8 
[FACTORY] Object supports IDispatch – WRAPPING! 
[PROXY] Created proxy #1 for FileSystemObject (Original: 0x03AD42D8) 
[FACTORY] !!! Replaced object with proxy! 

Method invocation with recursive object wrapping  

[PROXY #1] >>> Invoke: FileSystemObject.GetSpecialFolder (METHOD PROPGET) ArgCount=1 
[PROXY #1] Arg[0]: 2 
[PROXY #1] <<< Result: IDispatch:0x03AD6C14 (HRESULT=0x00000000) 
[PROXY] Created proxy #2 for FileSystemObject.GetSpecialFolder (Original: 0x03AD6C14) 
[PROXY #1] !!! Wrapped returned IDispatch as new proxy 
[PROXY #2] >>> Invoke: FileSystemObject.GetSpecialFolder.Path (METHOD PROPGET) ArgCount=0 
[PROXY #2] <<< Result: "C:\Users\home\AppData\Local\Temp" (HRESULT=0x00000000)

WScript.Shell operations

[CLSIDFromProgID] 'WScript.Shell' -> {72C24DD5-D70A-438B-8A42-98424B88AFB8} 
[CoGetClassObject] WScript.Shell ({72C24DD5-D70A-438B-8A42-98424B88AFB8}) Context=0x00000015 
[FACTORY] CreateInstance: WScript.Shell requesting IUnknown 
[PROXY] Created proxy #3 for WScript.Shell (Original: 0x03AD04B0) 
[PROXY #3] >>> Invoke: WScript.Shell.ExpandEnvironmentStrings (METHOD PROPGET) ArgCount=1 
[PROXY #3] Arg[0]: "%WINDIR%" 
[PROXY #3] <<< Result: "C:\WINDOWS" (HRESULT=0x00000000)

Dictionary operations 

[CLSIDFromProgID] 'Scripting.Dictionary' -> {EE09B103-97E0-11CF-978F-00A02463E06F} 
[PROXY] Created proxy #4 for Scripting.Dictionary (Original: 0x03AD0570) 
[PROXY #4] >>> Invoke: Scripting.Dictionary.Add (METHOD) ArgCount=2 
[PROXY #4] Arg[0]: "test" 
[PROXY #4] Arg[1]: "value" 
[PROXY #4] <<< Result: (void) HRESULT=0x00000000 
[PROXY #4] >>> Invoke: Scripting.Dictionary.Item (METHOD PROPGET) ArgCount=1 
[PROXY #4] Arg[0]: "test" 
[PROXY #4] <<< Result: "value" (HRESULT=0x00000000)

This output provides: 

• Complete object instantiation audit trail with CLSIDs  
• All method invocations with method names resolved via ITypeInfo  
• Full parameter capture including strings, numbers, and object references  
• Return value logging including nested objects  
• Object relationship tracking showing parent-child relationships  
• Log post processing allows for high fidelity command retrieval

Figure 12. Raw log output, parsed results, and original script.

Deployment

DispatchLogger is implemented as a dynamic-link library (DLL) that can be injected into target processes. 

Once loaded, the DLL: 

1. Locates debug output window or uses OutputDebugString  
2. Initializes critical sections for thread safety  
3. Hooks COM API functions using inline hooking engine  
4. Begins transparent logging  

No modifications to the target script or runtime environment are required. 

Advantages over alternative approaches

Approach	Coverage	Semantic visibility	Detection risk
Static analysis	Encrypted/obfuscated scripts missed	No runtime behavior	N/A
API monitoring	Low-level calls only	Missing high-level intent	Medium
Memory forensics	Point-in-time snapshots	No call sequence context	Low
Debugger tracing	Manual breakpoints required	Analyst-driven, labor-intensive	High
DispatchLogger	Complete late bound automation layer	Full semantic context	None

DispatchLogger provides advantages for: 

• WMI-based attacks: Complete query visibility, object enumeration, method invocation tracking  
• Living-off-the-land (LOTL) techniques: Office automation abuse, scheduled task manipulation, registry operations  
• Fileless malware: PowerShell/COM hybrid attacks, script-only payloads  
• Persistence mechanisms: COM-based autostart mechanisms, WMI event subscriptions  
• Data exfiltration: Filesystem operations, network object usage, database access via ADODB  
• Obsfuscation bypass: Working at the COM layer, method names and arguments are already fully resolved

Performance considerations 

Proxy overhead is minimal: 

• Each Invoke call adds one virtual function dispatch. 
• In the demo, logging I/O occurs via IPC. 
• Object wrapping is O(1) with hash map lookup. 
• There is no performance impact on non-COM operations. 

In testing with real malware samples, execution time differences were negligible. 

Limitations 

Current implementation constraints: 

• IDispatchEx: Not currently implemented (not used by most malware) 
• IClassFactory2+: Not currently implemented (may impact browser/HTA/WinRT) 
• Out-of-process COM: DCOM calls require separate injection into server process  
• Multi-threaded race conditions: Rare edge cases in concurrent object creation  
• Type library dependencies: Method name resolution requires registered type libraries  
• Process following: Sample code does not attempt to inject into child processes 
• 64-bit support: 64-bit builds are working but have not been heavily tested 

The sample code included with this article is a general purpose tool and proof of concept. It has not been tested at scale and does not attempt to prevent logging escapes.

Operational usage 

Typical analysis workflow: 

1. Prepare isolated analysis VM  
2. Inject DispatchLogger into target process  
3. Execute malware sample  
4. Review comprehensive COM interaction log  
5. Identify key objects, methods, and parameters  
6. Extract IOCs and behavioral signatures  

The tool has been tested against: 

• VBScript & Jscript using Windows Script Host (cscript/wscript) 
• PowerShell scripts 
• basic tests against .NET and Runtime Callable Wrappers (RCW) 
• VB6 executables with late bound calls and Get/CreateObject

Background and prior work 

The techniques presented in this article emerged from earlier experimentation with IDispatch while developing a JavaScript engine capable of exposing dynamic JavaScript objects as late-bound COM objects. That work required deep control over name resolution, property creation, and IDispatch::Invoke handling. This framework allowed JavaScript objects to be accessed and modified transparently from COM clients. 

The experience gained from that effort directly informed the transparent proxying and recursive object wrapping techniques used in DispatchLogger.

Conclusion 

DispatchLogger addresses a significant gap in script-based malware analysis by providing deep, semantic-level visibility into COM automation operations. Through transparent proxy interception at the COM instantiation boundary, recursive object wrapping, and comprehensive logging, analysts gain great insight into malware behavior without modifying samples or introducing detection vectors. 

The implementation demonstrates that decades-old COM architecture, when properly instrumented, provides powerful analysis capabilities for modern threats. By understanding COM internals and applying transparent proxying patterns, previously opaque script behavior becomes highly observable. 

DispatchLogger is being released open source under the Apache license and can be downloaded from the Cisco Talos GitHub page.

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

Ubuntu CVE-2026-3888 Bug Lets Attackers Gain Root via systemd Cleanup Timing Exploit

A high-severity security flaw affecting default installations of Ubuntu Desktop versions 24.04 and later could be exploited to escalate privileges to the root level.

Tracked as CVE-2026-3888 (CVSS score: 7.8), the issue could allow an attacker to seize control of a susceptible system.

"This flaw (CVE-2026-3888) allows an unprivileged local attacker to escalate privileges to full root access through the interaction of two standard system components: snap-confine and systemd-tmpfiles," the Qualys Threat Research Unit (TRU) said. "While the exploit requires a specific time-based window (10–30 days), the resulting impact is a complete compromise of the host system." 

The problem, Qualys noted, stems from the unintended interaction of snap-confine, which manages execution environments for snap applications by creating a sandbox, and systemd-tmpfiles, which automatically cleans up temporary files and directories (e.g.,/tmp, /run, and /var/tmp) older than a defined threshold.

The vulnerability has been patched in the following versions -

• Ubuntu 24.04 LTS - snapd versions prior to 2.73+ubuntu24.04.1
• Ubuntu 25.10 LTS - snapd versions prior to 2.73+ubuntu25.10.1
• Ubuntu 26.04 LTS (Dev) - snapd versions prior to 2.74.1+ubuntu26.04.1
• Upstream snapd - versions prior to 2.75

The attack requires low privileges and no user interaction, although the attack complexity is high due to the time-delay mechanism in the exploit chain.

"In default configurations, systemd-tmpfiles is scheduled to remove stale data in /tmp," Qualys said. "An attacker can exploit this by manipulating the timing of these cleanup cycles."

The attack plays out in the following manner -

• The attacker must wait for the system's cleanup daemon to delete a critical directory (/tmp/.snap) required by snap-confine. The default period is 30 days in Ubuntu 24.04 and 10 days in later versions.
• Once deleted, the attacker recreates the directory with malicious payloads.
• During the next sandbox initialization, snap-confine bind mounts these files as root, allowing the execution of arbitrary code within the privileged context.

In addition, Qualys said it discovered a race condition flaw in the uutils coreutils package that allows an unprivileged local attacker to replace directory entries with symbolic links (aka symlinks) during root-owned cron executions.

"Successful exploitation could lead to arbitrary file deletion as root or further privilege escalation by targeting snap sandbox directories," the cybersecurity company said. "The vulnerability was reported and mitigated prior to the public release of Ubuntu 25.10. The default rm command in Ubuntu 25.10 was reverted to GNU coreutils to mitigate this risk immediately. Upstream fixes have since been applied to the uutils repository."

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

Apple Fixes WebKit Vulnerability Enabling Same-Origin Policy Bypass on iOS and macOS

Apple on Tuesday released its first round of Background Security Improvements to address a security flaw in WebKit that affects iOS, iPadOS, and macOS.

The vulnerability, tracked as CVE-2026-20643 (CVSS score: N/A), has been described as a cross-origin issue in WebKit's Navigation API that could be exploited to bypass the same-origin policy when processing maliciously crafted web content.

The flaw affects iOS 26.3.1, iPadOS 26.3.1, macOS 26.3.1, and macOS 26.3.2. It has been addressed with improved input validation in iOS 26.3.1 (a), iPadOS 26.3.1 (a), macOS 26.3.1 (a), and macOS 26.3.2 (a). Security researcher Thomas Espach has been credited with discovering and reporting the shortcoming.

Apple notes that Background Security Improvements are meant for delivering lightweight security releases for components such as the Safari browser, WebKit framework stack, and other system libraries through smaller, ongoing security patches rather than issuing them as part of larger software updates.

The feature is supported and enabled for future releases starting with iOS 26.1, iPadOS 26.1, and macOS 26. In cases where compatibility issues are discovered, the improvements may be temporarily removed and then enhanced in a subsequent software update, Apple adds.

Users can control Background Security Improvements via the Privacy and Security menu in the Settings app. To ensure that they are automatically installed, it's advised to keep the "Automatically Install" option on.

It's worth noting that if users opt to have this setting disabled, they will have to wait until the improvements are included in the next software update. Viewed in that light, the feature is analogous to Rapid Security Response, which it introduced in iOS 16 as a way to install minor security updates.

"If a Background Security Improvement has been applied, and you choose to remove it, your device reverts to the baseline software update (for example, iOS 26.3) with no Background Security Improvements applied," Apple noted in a help document.

The development comes little over a month after Apple issued fixes for an actively exploited zero-day impacting iOS, iPadOS, macOS Tahoe, tvOS, watchOS, and visionOS (CVE-2026-20700, CVSS score: 7.8) that could result in arbitrary code execution.

Last week, the iPhone maker also expanded patches for four security flaws (CVE-2023-43010, CVE-2023-43000, CVE-2023-41974, and CVE-2024-23222) that were weaponized as part of the Coruna exploit kit.

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

AI Flaws in Amazon Bedrock, LangSmith, and SGLang Enable Data Exfiltration and RCE

Cybersecurity researchers have disclosed details of a new method for exfiltrating sensitive data from artificial intelligence (AI) code execution environments using domain name system (DNS) queries.

In a report published Monday, BeyondTrust revealed that Amazon Bedrock AgentCore Code Interpreter's sandbox mode permits outbound DNS queries that an attacker can exploit to enable interactive shells and bypass network isolation. The issue, which does not have a CVE identifier, carries a CVSS score of 7.5 out of 10.0.

Amazon Bedrock AgentCore Code Interpreter is a fully managed service that enables AI agents to securely execute code in isolated sandbox environments, such that agentic workloads cannot access external systems. It was launched by Amazon in August 2025.

The fact that the service allows DNS queries despite "no network access" configuration can allow "threat actors to establish command-and-control channels and data exfiltration over DNS in certain scenarios, bypassing the expected network isolation controls," Kinnaird McQuade, chief security architect at BeyondTrust, said.

In an experimental attack scenario, a threat actor can abuse this behavior to set up a bidirectional communication channel using DNS queries and responses, obtain an interactive reverse shell, exfiltrate sensitive information through DNS queries if their IAM role has permissions to access AWS resources like S3 buckets storing that data, and perform command execution.

What's more, the DNS communication mechanism can be abused to deliver additional payloads that are fed to the Code Interpreter, causing it to poll the DNS command-and-control (C2) server for commands stored in DNS A records, execute them, and return the results via DNS subdomain queries.

It's worth noting that Code Interpreter requires an IAM role to access AWS resources. However, a simple oversight can cause an overprivileged role to be assigned to the service, granting it broad permissions to access sensitive data.

"This research demonstrates how DNS resolution can undermine the network isolation guarantees of sandboxed code interpreters," BeyondTrust said. "By using this method, attackers could have exfiltrated sensitive data from AWS resources accessible via the Code Interpreter's IAM role, potentially causing downtime, data breaches of sensitive customer information, or deleted infrastructure."

Following responsible disclosure in September 2025, Amazon has determined it to be intended functionality rather than a defect, urging customers to use VPC mode instead of sandbox mode for complete network isolation. The tech giant is also recommending the use of a DNS firewall to filter outbound DNS traffic.

"To protect sensitive workloads, administrators should inventory all active AgentCore Code Interpreter instances and immediately migrate those handling critical data from Sandbox mode to VPC mode," Jason Soroko, senior fellow at Sectigo, said.

"Operating within a VPC provides the necessary infrastructure for robust network isolation, allowing teams to implement strict security groups, network ACLs, and Route53 Resolver DNS Firewalls to monitor and block unauthorized DNS resolution. Finally, security teams must rigorously audit the IAM roles attached to these interpreters, strictly enforcing the principle of least privilege to restrict the blast radius of any potential compromise."

LangSmith Susceptible to Account Takeover Flaw

The disclosure comes as Miggo Security disclosed a high-severity security flaw in LangSmith (CVE-2026-25750, CVSS score: 8.5) that exposed users to potential token theft and account takeover. The issue, which affects both self-hosted and cloud deployments, has been addressed in LangSmith version 0.12.71 released in December 2025.

The shortcoming has been characterized as a case of URL parameter injection stemming from a lack of validation on the baseUrl parameter, enabling an attacker to steal a signed-in user's bearer token, user ID, and workspace ID transmitted to a server under their control through social engineering techniques like tricking the victim into clicking on a specially crafted link like below -

• Cloud - smith.langchain[.]com/studio/?baseUrl=https://ift.tt/NRC9b34
• Self-hosted - <LangSmith_domain_of_the_customer>/studio/?baseUrl=https://ift.tt/NRC9b34

Successful exploitation of the vulnerability could allow an attacker to gain unauthorized access to the AI's trace history, as well as expose internal SQL queries, CRM customer records, or proprietary source code by reviewing tool calls.

"A logged-in LangSmith user could be compromised merely by accessing an attacker-controlled site or by clicking a malicious link," Miggo researchers Liad Eliyahu and Eliana Vuijsje said.

"This vulnerability is a reminder that AI observability platforms are now critical infrastructure. As these tools prioritize developer flexibility, they often inadvertently bypass security guardrails. This risk is compounded because, like 'traditional' software, AI Agents have deep access to internal data sources and third-party services."

Unsafe Pickle Deserialization Flaws in SGLang

Security vulnerabilities have also been flagged in SGLang, a popular open-source framework for serving large language models and multimodal AI models, which, if successfully exploited, could trigger unsafe pickle deserialization, potentially resulting in remote code execution.

The vulnerabilities, discovered by Orca security researcher Igor Stepansky, remain unpatched as of writing. A brief description of the flaws is as follows -

• CVE-2026-3059 (CVSS score: 9.8) - An unauthenticated remote code execution vulnerability through the ZeroMQ (aka ZMQ) broker, which deserializes untrusted data using pickle.loads() without authentication. It affects SGLang's multimodal generation module.
• CVE-2026-3060 (CVSS score: 9.8) - An unauthenticated remote code execution vulnerability through the disaggregation module, which deserializes untrusted data using pickle.loads() without authentication. It affects SGLang' encoder parallel disaggregation system.
• CVE-2026-3989 (CVSS score: 7.8) - The use of an insecure pickle.load() function without validation and proper deserialization in SGLang's "replay_request_dump.py," which can be exploited by providing a malicious pickle file.

"The first two allow unauthenticated remote code execution against any SGLang deployment that exposes its multimodal generation or disaggregation features to the network," Stepansky said. "The third involves insecure deserialization in a crash dump replay utility."

In a coordinated advisory, the CERT Coordination Center (CERT/CC) said SGLang is vulnerable to CVE-2026-3059 when the multimodal generation system is enabled, and to CVE-2026-3060 when the encoder parallel disaggregation system is enabled.

"If either condition is met and an attacker knows the TCP port on which the ZMQ broker is listening and can send requests to the server, they can exploit the vulnerability by sending a malicious pickle file to the broker, which will then deserialize it," CERT/CC said.

Users of SGLang are recommended to restrict access to the service interfaces and ensure they are not exposed to untrusted networks. It's also advised to implement adequate network segmentation and access controls to prevent unauthorized interaction with the ZeroMQ endpoints.

While there is no evidence that these vulnerabilities have been exploited in the wild, it's crucial to monitor for unexpected inbound TCP connections to the ZeroMQ broker port, unexpected child processes spawned by the SGLang Python process, file creation in unusual locations by the SGLang process, and outbound connections from the SGLang process to unexpected destinations.

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