• Data exfiltration activity increasingly leverages legitimate native utilities, commonly deployed third-party tools, and cloud service clients, reducing the effectiveness of static indicators of compromise (IOCs) and tool-based blocking strategies. 
• The Exfiltration Framework systematically normalizes behavioral and forensic characteristics of these tools, enabling cross-environment comparison independent of operating system, deployment model, or infrastructure domain. 
• By modeling execution context, parent-child process relationships, network communication patterns, artifact persistence, and destination characteristics, the framework exposes detection-relevant signals that remain stable even when tools are renamed, relocated, or operated within trusted infrastructure. 
• The analysis demonstrates that reliable detection requires correlation across endpoint, network, and cloud telemetry, with emphasis on behavioral baselining, contextual anomalies, and cumulative transfer analysis rather than protocol-level or allow-list–based controls.

Background

As defenders have improved their ability to detect malicious code, attackers have adapted by reducing their reliance on bespoke implants. As a result, data exfiltration is no longer primarily driven by custom malware or specialized tooling. Instead, many modern exfiltration operations leverage legitimate, widely deployed utilities already present in enterprise environments, along with benign cloud storage locations as the destination of the exfiltration connections. 

This shift significantly complicates detection. Tools and services used for routine business operations can be repurposed to transfer stolen data outside the network without triggering traditional security controls. In many real-world incidents, exfiltration does not rely on novel protocols, custom command-and-control (C2) infrastructure, or overtly malicious binaries. Instead, attackers abuse trusted, allow-listed tools such as cloud command-line interfaces, file synchronization utilities, managed file transfer platforms, and legitimate file storage services. In these scenarios, the distinction between legitimate use and malicious abuse is subtle, contextual, and difficult to identify. 

This research originated from a fundamental question: If attackers don’t require malicious software or infrastructure to exfiltrate data, what signals can defenders rely on to detect their behavior? 

Goal 

The Exfiltration Framework was developed to explore this question by systematically analyzing how legitimate tools are abused for data exfiltration. While many existing frameworks catalog the misuse of legitimate tools by platform or technology domain, the Exfiltration Framework takes a cross-platform perspective and categorizes tools by exfiltration tactic rather than environment or implementation. 

The goal of this project is not to catalog attack techniques or enumerate tools, but to understand how benign utilities are abused for data exfiltration and which telemetry defenders can realistically rely on for detection. By focusing on observable behavior rather than tool presence, this research aims to support detection strategies that remain effective even when attackers operate entirely within trusted software and permitted infrastructure. A secondary objective is to identify behavioral patterns that recur across tools and can be applied more generically to detect exfiltration activity. 

The Exfiltration Framework 

The Exfiltration Framework is a defensive project designed to systematically document how legitimate tools are abused for data exfiltration. Early in its development, the goal was to provide a comparative overview of exfiltration-capable tools, similar in spirit to matrix-style projects that summarize capabilities at a high level. While useful for classification, this approach proved insufficient for capturing the behavioral and forensic details required for detection and investigation. 

As a result, the framework evolved toward a structured, feature-oriented model inspired by projects such as LOLBAS, where tool capabilities, behaviors, and artifacts are documented in a consistent and extensible format. This design allows exfiltration-relevant characteristics to be organized clearly and compared across tools without oversimplifying their behavior. 

The framework is intentionally scoped to legitimate, widely available tools commonly present in enterprise environments. It does not attempt to catalog all possible exfiltration mechanisms, nor does it analyze custom malware, exploit-based techniques, or novel C2 protocols. Instead, it concentrates on utilities routinely used for legitimate purposes that can naturally blend into normal activity, making their abuse particularly difficult to detect.

Design goals and data model 

The Exfiltration Framework is designed to capture behavioral and forensic characteristics that are directly useful for detection, investigation, and comparative analysis. Rather than documenting tool functionality or attack procedures, each tool is represented using a structured, normalized schema that emphasizes how exfiltration manifests operationally across endpoint, network, and cloud telemetry. 

This normalization allows defenders to compare tools with very different implementations based on shared behavioral characteristics, and to reason about exfiltration activity independently of the specific utility involved. 

To reflect real-world enterprise environments, tools are grouped into three categories: 

• Built-in operating system tools, available by default on endpoints 
• Commonly deployed endpoint tools, installed for operational or administrative purposes 
• Cloud-native tools, designed to interact with cloud services and storage platforms 

This categorization illustrates how exfiltration can occur across multiple layers of the environment, from endpoints to cloud infrastructure, while highlighting differing detection trade-offs. 

Core framework fields and rationale 

The Exfiltration Framework is designed around the premise that detecting data exfiltration via legitimate tools requires understanding how those tools behave when misused, rather than relying on static identifiers or tool presence alone. Each field in the framework schema was selected to capture signals that defenders can realistically observe and correlate across endpoint, network, and cloud telemetry. 

Rather than attempting to model every possible abuse pattern, the framework focuses on a small set of fields that consistently influence detection outcomes across tools and environments.

• Tool identity and classification 
  Basic metadata such as tool name, category, and supported platforms provides essential context without implying malicious intent. Classification by deployment model — built-in operating system tools, commonly deployed endpoint tools, and cloud-native tools — helps frame expected behavior and informs detection trade-offs.  
  This distinction is important because tool legitimacy strongly influences both attacker behavior and defensive visibility. Built-in tools often benefit from implicit trust and extensive allow-listing, while cloud-native tools operate against shared infrastructure with limited network-level discrimination. Capturing this context allows defenders to reason about expected versus anomalous behavior for a given class of tool. 
• Execution characteristics 
  Execution-related fields capture how a tool is typically invoked when abused, including execution mode (interactive, background, headless), command-line usage, and parent-child process relationships. These attributes are frequently more stable indicators of misuse than the presence of a specific binary, particularly in scenarios involving masquerading or living-off-the-land techniques. 
  Execution context often provides early signals of abuse, such as tools launched by unexpected parent processes, executed from atypical directories, or run in unattended modes inconsistent with normal usage. By explicitly modeling these characteristics, the framework enables detection approaches that remain effective even when tools are renamed or relocated. 
• Network behavior 
  Network-focused fields describe how tools communicate during exfiltration, including protocol usage, destination types, authentication models, and connection patterns. Rather than relying on static indicators such as IP addresses or domains, the framework emphasizes behaviors that affect detection strategy, such as long-lived outbound connections, cloud API interactions, or peer-to-peer synchronization. 
  This abstraction is critical because many legitimate tools produce network traffic that appears benign in isolation. By capturing destination categories and communication patterns instead of specific endpoints, the framework supports detection approaches that focus on contextual anomalies, such as unexpected destinations, unusual transfer volumes, or deviations from baseline behavior. 
• Forensic artifacts 
  Forensic artifact fields document traces that may persist on disk or in system state, including configuration files, logs, cached credentials, scheduled tasks, or registry changes. These artifacts are particularly valuable for retrospective detection, incident response, and timeline reconstruction. 
  Importantly, the framework treats forensic artifacts as variable rather than guaranteed. Some tools leave extensive footprints, while others operate with minimal persistence or rely on in-memory execution. Explicitly modeling this variability helps defenders understand where forensic blind spots may exist and which tools require stronger reliance on real-time telemetry. 
• Detection focus areas 
  Instead of defining specific detection rules, the framework highlights a set of behavioral patterns observed when legitimate tools are used for exfiltration. These include transfers to network destinations that are unusual for that tool or environment, command-line arguments specific to a particular tool being provided to a differently named process and data volume inconsistencies. These focus areas are intentionally abstract, allowing defenders to adapt them to different environments, logging capabilities, and threat models. 

This design choice reflects the reality that effective detection logic is highly environment-specific. By emphasizing what to look for rather than how to detect it, the framework supports reuse across organizations and avoids coupling the research to a specific detection platform or rule format.

Example: Normalized Tool Representation 

To illustrate how these fields are applied, the following excerpt shows one particular entry in the framework, a normalized representation of the actionable items gleaned from research into the MOVEit Transfer tool.

This normalized representation enables tools with very different implementations to be compared based on shared behavioral characteristics, supporting consistent analysis across endpoint, network, and cloud contexts. The standardized format also facilitates reuse beyond manual analysis, including integration into automated or AI-assisted detection workflows.

Examples of tools covered in the framework 

The framework currently analyzes a curated set of legitimate tools observed in real-world exfiltration scenarios and commonly found in enterprise environments. 

Built-in operating system tools 

• PowerShell 
• robocopy 
• xcopy 
• bitsadmin 
• curl 
• wget 

Third-party endpoint tools 

• rclone 
• Syncthing 
• restic 
• GoodSync 
• MOVEit 
• PSCP 

Cloud tools 

• AWS CLI 
• AzCopy 
• Google Cloud CLI (gcloud) 
• S3 Browser 

This list is not intended to be exhaustive, but represents tools selected based on documented abuse in the wild, prevalence in enterprise environments, and relevance to defensive detection efforts.

Key research observations 

Analysis of these tools revealed several recurring patterns with direct implications for detection. Although individual utilities differ in implementation, their abuse for data exfiltration often converges in ways that undermine tool-centric detection approaches. The observations below highlight how attackers leverage legitimate functionality, existing trust relationships, and normal operational patterns to obscure exfiltration activity. 

Similarity of network traffic 

Across a wide range of tools analyzed in this research, outbound network traffic generated during data exfiltration often converges on common, legitimate patterns. Whether the utility is a native command-line tool, a third-party endpoint application, or a cloud client, data transfer typically occurs over standard application-layer protocols such as HTTPS. Typically the network traffic uses expected destination ports and encrypted payloads as well. This convergence reflects attackers’ preference for tools and services that are already permitted and widely used within enterprise environments. 

In practice, exfiltration performed via cloud command-line interfaces, storage clients, or synchronization tools frequently targets trusted cloud platforms or externally hosted infrastructure. Public reporting shows that attackers commonly leverage legitimate cloud services for data theft, resulting in outbound traffic that is difficult to distinguish from authorized business activity at the network layer. 

For example, a cloud storage client uploading data to an external bucket and a synchronization utility transferring files to a remote peer may both generate long-lived HTTPS sessions with steady outbound throughput. From a network perspective, these transfers are characterized by encrypted traffic over standard ports, sustained outbound connections, and destinations associated with legitimate cloud storage providers. This combination closely resembles routine backup or synchronization activity and has been observed in multiple ransomware and extortion investigations involving tools such as rclone and cloud storage clients. As a result, network flow log-based detection approaches based on protocol identification, destination allow-listing, or port filtering provide limited visibility into exfiltration activity.  

Layer 7 metadata such as Transmission Control Protocol (TCP) flags or certificate data may provide additional detection opportunities in some cases, but even there standard attributes were the norm. This convergence highlights the need to correlate network telemetry with execution context, data volume relative to baselines, and destination characteristics — such as ownership or prior association with the organization — rather than relying on network traffic alone. 

Variability of forensic artifacts 

While network-level behavior often converges across exfiltration tools, the forensic artifacts left on the endpoint can vary significantly depending on the utility and execution method used. Some tools generate a rich and persistent footprint, including configuration files, local state databases, cached credentials, scheduled tasks, or detailed logs. When present, these artifacts provide valuable context for incident response, supporting threat hunting, timeline reconstruction, and attribution, as observed in real-world abuse of tools such as rclone and Syncthing. While tool renaming is common and sometimes difficult to detect in process telemetry, masqueraded tools may still generate many of the same forensic artifacts, leading to additional opportunities for identification.  

Other tools operate with a much lighter or more transient footprint. Command-line utilities executed with inline arguments, temporary configurations, or fileless techniques may leave little evidence beyond short-lived process execution, command-line telemetry, and ephemeral network connections. Public reporting shows that PowerShell-based exfiltration can rely almost entirely on execution context and in-memory behavior, leaving few durable artifacts on disk. In these cases, forensic visibility depends heavily on the availability and quality of endpoint logging, including process creation, command-line auditing, and script execution telemetry. 

This variability reinforces a key finding of the research: There is no uniform forensic signature for exfiltration using legitimate tools. Effective detection therefore requires correlating endpoint telemetry with network and cloud data, rather than assuming that exfiltration activity will consistently leave persistent artifacts. 

Cloud-native tools blend into normal operations 

Cloud-native tools present a significant detection challenge because they operate within services that are already central to enterprise workflows. Authentication flows, API interactions, and data transfer patterns observed during exfiltration often closely resemble legitimate activity such as backups, deployments, or routine synchronization. Public incident reporting shows that attackers frequently abuse officially supported cloud clients to move data to attacker-controlled storage while maintaining the appearance of normal cloud usage. 

In these scenarios, traditional IOCs, such as domains or IP addresses, provide limited value. Cloud platforms rely on large, shared infrastructure, resulting in highly generic service endpoints used by both legitimate users and attackers. As a result, detecting or blocking exfiltration based on network indicators alone is often impractical and risks significant operational disruption. 

Compounding this challenge, many behavioral network detections explicitly allow-list major cloud providers to reduce noise from expected business activity. While operationally necessary, this practice further limits visibility into cloud-based exfiltration, enabling attackers to bypass both legacy IOC-based detections and higher-level behavioral controls by operating entirely within trusted cloud services. This is where cloud-native security products with visibility into which tenants, subscriptions or individual storage buckets are owned by the organization, as well as whether the identity initiating the file transfer typically interacts with that cloud resource, can assist with detection. 

Masquerading as a common technique 

Masquerading is frequently used to reduce the visibility of data exfiltration by exploiting assumptions about trusted binaries and execution contexts. Rather than introducing unfamiliar tools, attackers often rename legitimate utilities or execute them from locations typically associated with benign software, allowing exfiltration activity to blend into normal endpoint operations and undermining detections based solely on binary names or file paths. 

A well-documented example involves rclone, a legitimate cloud synchronization tool repeatedly abused in ransomware and data theft operations. Incident response reporting shows rclone binaries being renamed and staged in trusted locations to evade scrutiny while enabling large-scale data transfers to attacker-controlled cloud storage under the appearance of routine administrative activity. 

These cases demonstrate that filename- or path-based trust assumptions are insufficient for detecting exfiltration activity. Effective detection requires correlating execution context, parent process relationships, command-line usage, and network behavior to identify misuse of otherwise legitimate tools, particularly when they are deliberately presented as benign components of the operating environment. 

Exfiltration via small, incremental data transfers 

A recurring pattern across multiple exfiltration tools is the use of small, incremental data transfers instead of large, single exfiltration events. This technique, which MITRE tracks as T1030, relies on splitting data into smaller units and transmitting it over extended periods. By doing this, attackers can remain below volume-based detection thresholds and reduce the likelihood of drawing attention. This approach has been observed in real-world data theft and ransomware operations involving legitimate transfer and synchronization tools. 

This behavior is not protocol- or tool-specific. File transfer utilities, synchronization tools, cloud clients, and scripting environments can all be configured to transfer data gradually, often closely resembling routine background activity. Public reporting on the abuse of tools like rclone and Syncthing shows how repeated low-volume transfers can collectively result in significant data loss while remaining difficult to distinguish from legitimate use. 

Because the timing, size, and frequency of these transfers often align with expected operational patterns — such as business hours or periodic jobs — detection typically requires longitudinal analysis rather than single-event alerts. Without baselining normal usage, low-and-slow exfiltration can persist unnoticed. 

Stealth is often a function of policy, not tooling 

Stealth in exfiltration scenarios often results from organizational policy rather than technical sophistication. Tools that are explicitly permitted or widely deployed frequently operate under relaxed monitoring, creating low-friction paths for data exfiltration. 

In living-off-the-land scenarios, attackers deliberately abuse trusted utilities to benefit from existing allow-listing and policy exemptions, rather than advanced evasion techniques. Public reporting shows that legitimate cloud and synchronization tools are often misused precisely because their activity is expected and rarely scrutinized. In some ransomware incidents, attackers do not attempt to minimize volume or hide behavior at all, instead exfiltrating large amounts of data directly using trusted tools and infrastructure, relying on policy trust and limited inspection to avoid detection. 

Observation summary

The following table summarizes several of the trends observed during the longitudinal analysis detailed above into categories:

Conclusion

As data exfiltration increasingly relies on legitimate, trusted tools rather than custom malware, defenders must rethink how they approach detection. This research shows that meaningful visibility does not come from identifying tools in isolation, but from understanding the specific behaviors those tools exhibit when misused. By analyzing and normalizing execution patterns, network characteristics, and forensic artifacts across a wide range of benign utilities, the Exfiltration Framework provides a practical foundation for behavior-driven detection grounded in real telemetry. Ultimately, improving exfiltration detection requires not only broader visibility, but a deeper understanding of how trusted tools can be repurposed — and how those behaviors can be observed, contextualized, and detected in practice. 

Contributing to the Exfiltration Framework 

The Exfiltration Framework is intended to evolve with the threat landscape. Contributions from defenders, researchers, and incident responders are welcome, particularly when grounded in real-world observations of how legitimate tools are abused for data exfiltration.

Whether it is documenting additional tools, refining existing entries, or sharing detection-relevant insights, community input helps keep the framework accurate and practically useful. Details on how to contribute are available in the project repository. 

Key takeaways 

• Legitimate tools are frequently abused for data exfiltration, making tool presence alone an unreliable detection signal. 
• Detection difficulty increases with tool legitimacy and native or cloud integration. 
• Behavioral signals — such as execution context, timing, data volume, authentication, and destination — are more reliable than static indicators when evaluated together. 
• Masquerading and low-and-slow transfer techniques exploit trust assumptions and volume-based detection thresholds. 
• Effective detection requires correlating endpoint, network, and cloud telemetry and baselining expected tool behavior. 

Acknowledgements 

We would like to thank the following researchers who have contributed to this project, via research into use of tools for exfiltration, review of the paper and framework, or general guidance and input: 

• Dariia Deshunina 
• Jan Kotrady 
• Josh MacKenzie 
• Melvin Wiens 
• Nasreddine Bencherchali 
• Nick Randolph 
• Onur Erdogan 
• Radka Viskova 
• Ray McCormick 
• Robert Harris

Cisco Talos Blog – ​Read More

Introduction 

A few years ago, most cyberattacks still depended heavily on human effort—skilled operators manually probing systems, testing vulnerabilities, and executing campaigns step by step. 

That model is quietly breaking down. 

In conversations with security teams and analysts over the past year, one theme keeps coming up: attackers are no longer just using tools—they’re starting to deploy systems that can think, adapt, and act on their own. This is where AI-powered cyber warfare begins to shift from buzzword to reality. 

At the center of this shift are autonomous attack agents, AI-driven systems that don’t just assist attackers but actively participate in decision-making. And that changes the threat landscape in a very real way. 

What is AI-Powered Cyber Warfare? 

At its simplest, AI-powered cyber warfare refers to the use of artificial intelligence and machine learning to enhance cyberattacks. But that definition doesn’t quite capture what’s happening on the ground. 

What’s different now is how AI is being used. 

Instead of just automating repetitive tasks, attackers are beginning to rely on AI to: 

• Continuously scan and map attack surfaces 

• Prioritize targets based on probability of success 

• Adjust tactics mid-attack 

• Learn from failures and retry with improved strategies 

One security researcher recently described it as “moving from scripts to systems.” That distinction matters. Scripts execute instructions. Systems adapt. 

This is why the AI threat landscape feels more unpredictable today—it’s no longer just about known techniques, but evolving behavior. 

Understanding Autonomous Attack Agents 

If there’s one concept security leaders are increasingly concerned about, it’s autonomous attack agents. 

These aren’t hypothetical. Early versions are already being observed in the wild—particularly in automated reconnaissance and vulnerability scanning campaigns. 

For example, researchers have documented AI-assisted tools that can: 

• Crawl entire infrastructures in minutes 

• Identify misconfigurations across cloud environments 

• Chain vulnerabilities together without manual input 

In one recent case study discussed in security circles, an AI-assisted system was able to simulate multiple attack paths against a target environment and automatically select the most efficient route. That’s a level of decision-making that traditionally required experienced human operators. 

This is what makes AI attack agents so significant—they compress both time and expertise. What once required a skilled team can increasingly be done by a single operator backed by intelligent systems. 

How AI is Changing Cyberattacks 

The shift toward AI-driven attacks is already visible across several fronts. 

1. AI-Powered Malware 

We’re seeing early signs of AI-powered malware that can alter its behavior to avoid detection. Instead of relying on fixed signatures, these threats experiment—adjusting execution patterns until they find a way through. 

While still evolving, this approach is forcing defenders to rethink how detection works. 

2. Smarter Phishing and Deepfakes 

Perhaps the most visible impact of AI is in phishing. 

Security teams report a noticeable increase in highly personalized phishing emails—messages that reflect tone, context, and even internal communication styles. With generative AI, attackers can now scale this level of personalization effortlessly. 

Add deepfake audio or video into the mix, and AI-driven cyber attacks start to blur the line between technical compromise and social engineering. 

3. Real-Time Decision Making 

AI doesn’t wait. 

Attack systems can process signals in real time—whether it’s detecting a defensive response or identifying a new entry point—and adjust instantly. This gives attackers a speed advantage that traditional defenses often struggle to match. 

4. Scalable, Automated Attacks 

Automation isn’t new in cybersecurity, but AI takes it further. 

With automated penetration attacks, a single campaign can test thousands of variations simultaneously. Instead of guessing what might work, attackers can experiment at scale. 

A Rapidly Evolving Threat Landscape 

From an analyst’s perspective, the biggest shift isn’t just technical—it’s operational. 

We’re moving from a world of occasional, targeted attacks to one of continuous, adaptive pressure. 

That translates into: 

• Shorter detection and response windows 

• A constant stream of attack attempts 

• More sophisticated and evolving tactics 

• A growing presence of intelligent cyber threats 

In discussions with CISOs, a common concern is fatigue—not just human fatigue, but system fatigue. Defenses designed for periodic threats are now dealing with persistent, automated adversaries. 

Blaze AI and the Shift Toward AI-Driven Defense 

If attackers are using AI to scale and adapt, defenders are being pushed in the same direction. 

This is where platforms like Blaze AI become relevant—not as a silver bullet, but as part of a broader shift toward intelligent defense. 

Instead of relying purely on predefined rules, Blaze AI focuses on: 

• Detecting patterns and anomalies in real time 

• Automating threat analysis and response 

• Providing visibility into emerging AI-driven cyber threats 

From what we’re seeing across the industry, this reflects a larger trend: cybersecurity is becoming a contest of learning systems. In other words, AI vs cybersecurity defense is no longer a future concept—it’s already underway. 

How to Defend Against AI-Powered Cyber Attacks 

There’s no single solution to counter AI-powered cyber warfare, but there are clear priorities emerging across organizations: 

1. Adopt AI-Driven Security Tools 

Static defenses struggle against adaptive threats. AI-based systems help identify patterns that don’t match known attack signatures. 

2. Strengthen Threat Intelligence 

Understanding emerging AI security risks is critical. The faster teams can contextualize new threats, the better they can respond. 

3. Implement Zero-Trust Architectures 

Limiting access and continuously verifying users reduces the attack surface—especially important against automated systems. 

4. Don’t Ignore the Human Layer 

Even the most advanced attacks still exploit human behavior. Training employees to recognize sophisticated phishing and manipulation attempts remains essential. 

The Future of Cyber Warfare 

Looking ahead, the trajectory is fairly clear. 

We’re entering a phase where artificial intelligence in cyber warfare becomes standard practice on both sides. Attackers will continue experimenting with autonomy, while defenders will invest in systems that can respond just as quickly. 

The question isn’t whether AI will dominate cyber operations—it’s how quickly organizations can adapt to that reality. 

Conclusion 

From an analyst standpoint, this moment feels like an inflection point. 

The rise of autonomous attack agents, AI-powered malware, and increasingly intelligent cyber threats signals a shift toward faster, more adaptive cyber conflict. 

Organizations that treat this as a distant concern risk falling behind. Those that start integrating AI into their defense strategy today will be far better positioned for what’s coming next. 

Don’t wait for threats to outpace your defenses. Experience how Cyble Blaze AI can transform your security operations with predictive intelligence and autonomous response. Request a personalized demo today and take the first step toward truly proactive cybersecurity. 

Frequently Asked Questions (FAQs) about AI-powered cyber warfare 

1. What are autonomous attack agents? 

Autonomous attack agents are AI systems capable of independently identifying vulnerabilities and launching cyberattacks with minimal human intervention. 

2. How is AI used in cyber warfare? 

AI is used to automate attacks, improve targeting, evade detection, and scale operations more efficiently. 

3. Is AI making cyberattacks more dangerous? 

Yes. AI increases both the speed and sophistication of cyberattacks, making them harder to detect and respond to. 

4. What is Blaze AI in cybersecurity? 

Blaze AI is an artificial intelligence-powered cybersecurity solution that combines intelligence and automation to detect, analyze, and respond to modern cyber threats. 

The post AI-Powered Cyber Warfare: How Autonomous Attack Agents Are Changing the Threat Landscape appeared first on Cyble.

Cyble – ​Read More

• 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:

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: 

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

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: 

The ClassFactoryProxy intercepts CreateInstance calls and handles both cases:

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.

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. 

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: 

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: 

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.

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:

Reference counting 

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

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:UsershomeAppDataLocalTemp" (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

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

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.

Cisco Talos Blog – ​Read More

As part of a recent live expert panel, ANY.RUN together with threat researcher and ethical hacker Mauro Eldritch explored biggest security risks companies should be prepared for in 2026. 

The discussion covered several relevant cases, from the Lazarus IT Workers operation to the rapid rise of AI-driven phishing attacks, and examined the common thread behind them: trust abuse. 

Below are the key takeaways for those seeking a clearer view of modern cyber risks and how to prepare as a SOC leader. 

Watch the full panel on our YouTube channel

Key Takeaways 

• Trust abuse is becoming a primary attack vector, driven by AI-powered phishing and identity-based infiltration. 

• Attacks increasingly lack clear indicators, making detection difficult for traditional SOC workflows. 

• Focus on early detection through behavioral visibility, context, and process-based security. 

• Combine sandbox analysis, threat intelligence, and contextual enrichment for faster, more accurate decisions. 

Trust Abuse: Top Business Risk for 2026 

In 2026, many cyberattacks don’t look like attacks at all. Instead of exploiting technical vulnerabilities, threat actors increasingly exploit human trust. This tactic is known as trust abuse, and it’s what many modern cyber threats are based on. 

Businesses inevitably rely on trust between employees, systems, vendors, and partners. Without it, organizations cannot operate efficiently. Threat actors know what, so they’ve learnt to mimic legitimate identities, infiltrate communication channels and everyday workflows, and turn employees into unwitting entry points. 

AI-assisted social engineering pushes trust abuse even further. These attacks closely resemble legitimate activity and often fail to trigger traditional alerts. For security leaders, this changes how risk must be understood.  

Risk mitigation is no longer only about patching vulnerabilities or strengthening perimeter defenses. Detecting trust abuse requires visibility into behavior, context, and how trust moves inside the enterprise.  

Case #1: Implications of Lazarus APT Infiltration  

Lazarus, a North-Korean state-sponsored threat actor, has shifted its tactics. Instead of relying only on malware, the group infiltrates Western and Middle Eastern companies to conduct corporate espionage. 

The scheme was investigated by Mauro Eldritch and Heiner García from NorthScan inside ANY.RUN’s controlled infrastructure. The researchers were able to trap the attackers in a sandbox environment and observe their activity while the threat actors believed they had gained access to a corporate network. 

Lazarus operation is a vivid example of trust abuse in a business environment. No advanced malware was involved in the attack initially. Because of that, the potential implications for the victims can be catastrophic. Attacks like that don’t trigger alerts; there’s simply nothing suspicious to detect. 

This is why, unlike short-lived malware campaigns, trust-based infiltrations can persist much longer. Once attackers gain access, they may embed themselves deeper in the organization or even place additional operatives inside the company. 

ANY.RUN exposed this campaign before the broader market. The investigation was conducted entirely within our controlled infrastructure, which allowed researchers to observe attacker behavior in real time. 

Read more on Lazarus case investigation supported by ANY.RUN 

But most companies do not have the resources to monitor suspicious activity at this level. 

In practice, risk mitigation depends on the ability to detect and interpret unusual behavior early, before it escalates into a full incident. Trust abuse attacks make early visibility and detection critical for enterprise security. 

Case #2: Modern AI-Powered Phishing  

Phishing attacks today look very different from the obvious scam emails many people are used to spotting. With AI-assisted tools, threat actors can now mimic completely normal email conversations, using polished language and highly personalized content. 

AI makes these attacks both believable and scalable. The core vulnerability here is human trust, which becomes an easy entry point for attackers. 

Modern phishing campaigns increasingly focus less on technical exploits and more on manipulating communication chains and legitimate domains that employees already trust. 

As a result, traditional security tools are often left with no clear indicators of compromise to detect. These attacks blend into normal business communication, making them much harder to identify before damage occurs. 

Building a SOC That Prevents Trust Abuse Attacks 

To address this challenge, modern security requires a layered approach. Early detection does not depend on a single tool but on a set of coordinated processes. In particular, effective defense relies on three core SOC activities: monitoring, triage, and threat hunting. 

Traditional security tools are important to have, but they aren’t universal. Unless they can show what happens after a user interacts with a suspicious file, link, or attachment, organizations may lack the full visibility needed to understand the threat. This gap leaves companies vulnerable to increasingly evasive attack techniques. 

ANY.RUN helps strengthen these processes by providing greater visibility, faster investigations, and reliable threat context.

Monitoring: Detecting Threats Early 

Effective monitoring helps identify threats before they reach internal systems, preventing breaches. ANY.RUN enhances monitoring by enabling teams to: 

• Detect emerging threats early: By tapping into real-time intelligence from live attack data from 15K companies 

• Maintain focus: Get only relevant signals through curated, high-confidence data 

• Reduce alert noise: Gain continuous visibility and instant IOC enrichment drives confident decision-making 

Rapid Triage: Understanding Alerts Faster 

Triage is critical for handling high alert volumes and avoiding delays in response. ANY.RUN helps streamline triage by allowing teams to: 

• Cut investigation time with rapid, interactive sandboxing for files and URLs providing in-depth view of behavioral activity. 

• Reduce escalations with behavioral and contextual insight that enrich alerts for confident decisions by Tier-1 analysts. 

• Lower operational costs by avoiding tool sprawl while delivering context-rich visibility into threats. 

Threat Hunting: Identifying Patterns Proactively 

Threat hunting focuses on uncovering patterns and anticipating attacker behavior. ANY.RUN supports proactive hunting by enabling teams to: 

• Get early warning signs: Analysts can easily correlate indicators, infrastructure, and historical activity. 

• Research and monitor trends: Identify relationships between campaigns, industries, regions, and threat actors. 

• Explore TTPs: Detect reused techniques and infrastructure to build clearer profiles of attacker behavior. 

By strengthening these three processes, organizations can achieve earlier detection, faster response, and more efficient SOC operations, reducing the risk of modern, trust-based attacks. 

Conclusion  

Enterprise cyber threats are shifting toward identity-based and trust-driven attacks. Campaigns like Lazarus and AI-powered phishing show that attackers no longer rely solely on malware or exploits. 

For decision-makers, this means rethinking how risk is assessed and how security operations are structured. Visibility, context, and speed are becoming critical factors in effective defense. 

Organizations that adapt their SOC processes to these realities will be better positioned to detect threats early and prevent incidents before they escalate. 

About ANY.RUN 

ANY.RUN delivers interactive malware analysis and actionable threat intelligence trusted by more than 15,000 organizations and 600,000 security analysts worldwide.   

Interactive Sandbox, Threat Intelligence Lookup, and Threat Intelligence Feeds help SOC and MSSP teams analyze threats faster, investigate incidents with deeper context, and detect emerging attacks earlier.   

ANY.RUN meets enterprise security and compliance expectations. The company is SOC 2 Type II certified, reinforcing its commitment to protecting customer data and maintaining strong security controls. 

The post Lazarus, AI, and Trust Abuse: Top Enterprise Cybersecurity Risks 2026  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More