Nessus now has Windows LAPS Support
Summary: Nessus now has the ability to leverage accounts managed by Microsoft Windows LAPS. How LAPS works: Since LAPS managed accounts have their passwords rotated routinely, users cannot just directly provide the credentials in their Scan Policy. Before this change, users would instead have to make an additional privileged account on each LAPS enabled Host to provide to Nessus. Currently Nessus supports Entra LAPS allowing a scan to pull LAPS Managed Credentials from a customer’s remote Entra instance. Now, Nessus can do the same for Windows LAPS, allowing customers with local LAPS setups to gain the same benefits! Without Windows LAPS support, customers must make dedicated account for Nessus to use to scan targets Change: With this LAPS support change, during the startup phase of a scan, Nessus will reach out to a customer provided Domain Controller hosting an AD forest with LAPS enabled, and pull a list of all Local Admin Accounts for devices managed by LAPS. Nessus will then attempt to use these retrieved LAPS managed accounts as credentials when attempting to access a target host. With Windows LAPS Support, Customers need only provide a single Credential that allows Nessus to retrieve the actual credentials for LAPS Managed Devices How to enable it: To make use of Nessus’ Windows LAPS support, a customer needs only to provide the necessary info to their scan/policy via the Windows LAPS Credential. They’ll need to provide us the IP of the DC, Credentials for an account on that DC with the necessary permissions*, and the DistinguishedName of the OU that contains their LAPS managed devices. *The Account for retrieving Windows LAPS credentials needs the following permissions General Recommend the Account be added to the BUILTIN/Administrators AD Group as it grants all required permissions, including: Access to the $Admin Able to log on to the DC remotely Able to run Powershell WMI and DCOM access to Root/CIMV2 WMI Namespace LAPS Permissions LapsADReadPasswordPermission rights to the LAPS OU Be an Authorized Password Decryptor in the LAPS GPO (without this, Nessus will not be able to retrieve passwords protected by LAPS Encryption). Members of the Domain Administrators group are Authorized Password Decryptors by default. For additional information see: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview Impact: Customers using Rotating Host passwords managed through Microsoft Windows LAPS can now leverage these credentials in their Nessus scans for more secure scanning configurations. Target Release Date: Nessus, T.VM On/About 09 JUN 2025 T.SC TBD
Include/Exclude Path and Tenable Utils Unzip added to Log4j Detection
Summary Tenable has updated the Apache Log4j detection plugins. The Windows plugin will now honor the Include/Exclude Filepath configuration option. The Linux/UNIX plugin will now use the version of ‘unzip’ supplied with the Nessus Agent, when enabled in the Agent’s configuration, and correctly inspect the MANIFEST.MF and pom.properties files. Change Before this update, plugin 156000, Apache Log4j Installed (Linux / Unix), would fail to detect Log4j in specific scan scenarios. The plugin uses several inspection methods to determine if a JAR file is a copy of Log4j. During Nessus Agent scans, as well as scans with ‘localhost’ as a target, the plugin was not properly executing the unzip command to inspect META-INF/MANIFEST.MF and pom.properties files in the JAR archive. If this method was the only option that would result in a successful detection, the copy of Log4j would not be detected properly. In addition, the plugin had failed to launch the unzip binary supplied with the Agent when inspecting files in JAR archives. Note: The Nessus Agent can be configured to use find and unzip binaries that it provides, instead of those supplied by the asset’s operating system. See https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Agent_Performance_Options for more information. Also before this update, plugin 156001, Apache Log4j JAR Detection (Windows), would fail to honor the directories included or excluded for full-disk searches configured in the Windows Include Filepath and Windows Exclude Filepath directives in the Advanced Settings of a scan config. Note: Configuration of these options is described in https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Windows_filesearchOptions. After this update, plugin 156000 will use the Agent-supplied copy of unzip when configured to do so. If this option is not enabled in the scan config, the plugin will use the existing method to find and execute an archive utility supplied by the asset’s operating system. In either case, the plugin will properly inspect Log4j’s MANIFEST.MF and pom.properties files as a version source. Plugin 156001 already properly inspects these files. Also after this update, plugin 156001’s Powershell code will now honor directories included or excluded by the Filepath directives. Plugin 156000 already supported this feature. Impact When scanning Linux / UNIX assets via 'localhost' (i.e. scanning the scanner itself) or with the Nessus Agent, additional Log4j instances from MANIFEST.MF or pom.properties sources may be reported. For Linux Nessus Agents with "Use Tenable supplied binaries for find and unzip" enabled and "Agent CPU Resource Control - Scan Performance Mode" set to Low, plugin 156000 will now properly limit CPU usage during scans. As noted in the product documentation, “Note: Setting your process_priority preference value to low could cause longer running scans. You may need to increase your scan-window timeframe to account for this value.” Customers should be aware of this configuration setting and potential changes to the results provided in the Log4J detection results. When scanning Windows targets, Log4j JAR files stored in paths specified in the Windows Exclude Filepath configuration will no longer be detected. Log4j JAR files stored in paths or drives specified in the Windows Include Filepath configuration that had not been previously scanned will now be detected, assuming they can be assessed before the plugin’s configured timeout has been reached. Plugins 156000 - Apache Log4j Installed (Linux / Unix) 156001 - Apache Log4j JAR Detection (Windows) Target Release Date September 1, 2025
Active Directory Starter Scan Background As part of our...
Active Directory Starter Scan Background As part of our endeavor to help reduce our customers’ cyber exposure, we are releasing a Starter Scan template along with plugins that will peel the onion around Active Directory Security. We hope customers will leverage these plugins as a starting point and consider an Active Directory Vulnerability Management solution for more holistic determination, given Active Directory breaches are ever-increasing and extremely devastating. Change Ten plugins checking for common Active Directory misconfigurations / vulnerabilities are being released. Active Directory controller credentials will be required for these plugins to run. Active Directory specific scan templates are also being released for Nessus Professional, Tenable.sc and Tenable.io. Dashboards for Tenable.sc and Tenable.io will also be available. Impact Customers will be able to run scans highlighting Active Directory issues. Note that these are starter Active Directory checks. For more complete coverage, we strongly recommend considering an Active Directory VM solution. Note that these plugins are not available on Nessus Agents. Plugins 150480 AD Starter Scan - Kerberoasting 150481 AD Starter Scan - Weak Kerberos encryption 150482 AD Starter Scan - Kerberos Pre-authentication Validation 150483 AD Starter Scan - Non-Expiring Account Password 150484 AD Starter Scan - Kerberos Krbtgt 150485 AD Starter Scan - Unconstrained delegation 150486 AD Starter Scan - Dangerous Trust Relationship 150487 AD Starter Scan - Primary Group ID integrity 150488 AD Starter Scan - Null sessions 150489 AD Starter Scan - Blank passwords Release Date Thursday 29 of July 2021
Oracle WebLogic: Patch Mapping Improvements
Oracle WebLogic: Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the installed version of Oracle WebLogic. How Patch Mapping Works for Oracle WebLogic Scans Prior to these improvements, the WebLogic version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including WebLogic, are enumerated in one of two possible ways: Linux Local Detections: oracle_enum_products_nix.bin (plugin ID 71642, requires SSH credentials) Windows Local Detections: oracle_enum_products_win.nbin (plugin ID 71643, requires SMB credentials) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 73913, oracle_weblogic_server_installed.nbin, collects this information, and then reports the install and its determined version (patch level). Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out-of-band cycle, or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 14.2.1.0.0.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on a mapping table. Plugin ID 73913 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping table is still checked, and a version comparison is performed to determine the highest patch level present. In its output, plugin ID 73913 will now also report all of the installed patches for the ORACLE_HOME in which the detected WebLogic application resides. Expected Impact Improved accuracy in version detections for Oracle WebLogic resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins 73913, oracle_weblogic_server_installed.nbin Potentially any Oracle WebLogic local vulnerability check plugins Targeted Release Date Monday, June 9, 2025Improved Printer Fingerprinting
Summary This document addresses an issue where network printers generate unnecessary prints when scanned, even with the "Don't Scan Printers" setting enabled. The fix involves improving the SNMP identification process for printers by falling back to default community strings and ports if an incorrect community string is initially configured. Background Currently, if a customer configures an incorrect SNMP v1/v2(c) community string for a device, Plugin ID 11933 / "Do not scan printers" fails to revert to using well-known, default SNMP v1/v2(c) community strings and ports, unlike other plugins. This failure can prevent accurate identification of network printers, leading to them being scanned and in some cases, may inadvertently queue print jobs on printers Impact The following assumes the user has enabled the "Do not scan printers" setting in their scan policy and the network printer is correctly identified as such: Potential Decrease in Reported Vulnerabilities: Network printers will be less heavily scanned, potentially leading to a decrease in reported vulnerabilities related to these devices. Slight Increase in Packet Traffic: There will be an increase of approximately three packets per host as the system attempts fallback SNMP connections. Printers Marked as "Dead": Network printers that are successfully identified via SNMP will be marked as "dead" and will not be scanned further. This change aims to enhance the effectiveness of identifying network printers using SNMP, thereby reducing unnecessary and potentially damaging traffic directed at these devices. The resulting decrease in reported vulnerabilities is an expected outcome, as identified printers will no longer be subjected to heavy scanning. Users can continue to scan network printers by enabling the "Scan Network Printers" setting under “Host Discovery -> Fragile Devices -> Scan Network Printers” in the scan policy. This ensures that printers are scanned and not marked as dead, irrespective of fingerprinting. Affected Plugins 11933 ( "Do not scan printers") Affected Scan Policy Settings Discovery -> Host Discovery -> Fragile Devices -> Scan Network Printers Tenable Security Center Tenable Vulnerability Management Tenable Nessus Target Release Date: Monday, September 15, 2025New Plugin Family: Tencent Linux Local Security Checks
note: This announcement is to update the target release date. Summary Tenable will now provide vulnerability check plugins for Tencent Linux. Impact Customers with Tencent Linux systems in their environments will be able to scan them for vulnerabilities. These plugins will have the family “Tencent Linux Local Security Checks”. These plugins do not have agent support at this time. Target Release Date June 16, 2025 (originally May 19, 2025)
Find & Unzip Execution Options Summary Instead of...
Find & Unzip Execution Options Summary Instead of running native OS commands of “find” and “unzip”, plugins will use binaries included within the plugin feed for agent-based scanning. This allows CPU consumption to be controlled for the Tenable Nessus Agent for the ‘find’ command. This change will not affect or limit memory consumption. An additional benefit is that if ‘find’ or ‘unzip’ are not found natively on the OS, using from the feed allows full plugin execution with these commands to continue. What is the impact? The change should be transparent to customers and no action is required to be taken except for new scans if you’d like to opt-in to this feature. New Scans Be aware if you have adjusted the Agent CPU settings of Scan Performance to a setting other than the default, which is High, the resulting scan findings may be different than previous scans with the same configuration. This is because the scan may experience timeouts in finding files due to the lower CPU resources. See the next section for how to opt-in to the change, if desired. Existing Scans This change will not apply. The native OS binaries will continue to be used and not subject to Tenable Nessus Agent CPU control settings. PCI-DSS Scans This change will not apply. The native OS binaries will continue to be used and not subject to Tenable Nessus Agent CPU control settings. Due to the PCI-DSS standard requirements, the most complete scan results are required for reporting. Audits Due to the need for thorough and complete results, Audits do not leverage the find or unzip binaries from the Tenable feed. How do I opt-in to the change? An advanced setting within the scan configuration will allow customers to opt-in to using the binaries from the feed. By default, native OS commands will run for ‘find’ and ‘unzip’ as before. Please note, these commands are not subject to agent CPU constraints. For PCI scanning and existing scans, the scan template setting will be not visible and the scanning behavior will be equivalent to opting-out. What are the affected plugins? At the time of this release highlight publication, the following plugins are leveraging find or unzip: Find 142023 - Apache Cassandra Installed (Linux) 133766 - Apache Maven Installed (Linux / Unix) 135172 - Oracle NoSQL Database Installed (Linux) 117706 - MagniComp SysInfo Installed (Linux/UNIX) 111679 - FasterXML Jackson Databind Detection for Linux/UNIX 112063 - Kubernetes Installed (Linux) 136340 - nginx Installed (Linux/UNIX) 131566 - Atlassian Jira Installed (Unix / Linux) 147817 - Java Detection and Identification (Linux / Unix) 132771 - Palo Alto Cortex XSOAR Installed (Unix / Linux) 132872 - Foxit Reader Installed (Linux) 174788 - SQLite Local Detection (Linux) 151883 - Libgcrypt Installed (Linux/UNIX) 99671 - Apache Struts Detection for Linux/UNIX 156000 - Apache Log4j Installed (Linux / Unix) 141394 - Apache HTTP Server Installed (Linux) 71642 - Oracle Installed Software Enumeration (Linux / Unix) 156551 - Oracle MySQL Enterprise Monitor Installed (macOS) 124276 - Oracle Tuxedo Installed (Linux/UNIX) 73913 - Oracle WebLogic Server Detection 133962 - Sophos Anti-Virus Installed (Linux) 186361 - VMWare Tools or Open VM Tools Installed (Linux) 187057 - OwnCloud OwnCloud Installed (Linux) 70349 - Adobe Acrobat Installed (Mac OS X) 72202 - JBoss Detection 147022 - SAP Adaptive Server Enterprise (ASE) Installed (Linux) 163488 - Terraform Configuration Detection for Linux/UNIX 77028 - IBM Installation Manager Detection (Linux / Unix) 145032 - IBM WebSphere eXtreme Scale (Linux) 144633 - IBM MQ Server and Client Installed (Linux) 136341 - Dell EMC Data Protection Central Installed (Linux) 133964 - SELinux Status Check 159273 - Dockerfile Detection for Linux/UNIX 174164 - Google Protobuf Go Module Installed (Linux/UNIX) 158567 - Citrix Workspace App Installed (nix) 55420 - Adobe Reader Installed (Mac OS X) Unzip 193884 - CrushFTP Server Installed (Linux / Unix) 130175 - Apache Tomcat Local Detection 166230 - Apache Commons Text JAR Detection 176069 - Potix ZK Framework Installed (Linux) 130595 - Jenkins Installed (Linux) 123005 - Spring Framework JAR Detection 156000 - Apache Log4j Installed (Linux / Unix) 192571 - Fortra FileCatalyst Direct Server Installed (Linux / Unix) 72202 - JBoss Detection 134049 - Spring Projects Linux Detection 185488 - IBM WebSphere Application Server Liberty Installed (Linux / Unix) 170106 - TIBCO JasperReports Library JAR Detection Target Release Date July 9, 2024 - Tenable Vulnerability Management and Nessus July 15, 2024 - Tenable Security CenterRed Hat: Custom RPM Repository Handling Improvements...
Red Hat: Custom RPM Repository Handling Improvements Summary Users with custom Red Hat repository naming conventions in their enterprise can now upload a custom mapping file in json format that maps custom RPM repository relative URLs to the official Red Hat counterparts for the purposes of vulnerability scanning. Problem Many Red Hat and Tenable customers utilize custom repository configurations and/or mirrors. In these cases, where neither the configured repository label or URL match Red Hat’s official mapping, Tenable plugins are unable to determine what software updates are available to the scan target. This can result in an increased number of potential false positive findings for Red Hat Local Checks. Solution With this update, we have introduced a method that allows users to upload a json file via their scan policy that maps their internal custom repository relative URL to the official Red Hat label and URL of the repository it mirrors. To upload this json file to your scan policy, go to “Settings > Advanced > Vulnerability Options > Custom Red Hat Repository Mapping” and click on the “Add File” link. For a more detailed overview of how this works in practice, please refer to the following user guide: How Red Hat Local Vulnerability Checks Use Repositories To Determine Scope Impacted Plugins All plugins in the Red Hat Local Security Checks family New plugin added: Plugin ID 233963, redhat_custom_repos.nasl Updated Scan Policy Templates Nessus Scanner Advanced Scan Advanced Dynamic Scan Basic Network Scan Nessus Agents Advanced Agent Scan Basic Agent Scan Targeted Release Date Nessus and Tenable VM: Monday, April 14, 2025 Tenable Security Center: TBCOracle Enterprise Manager Agent: Patch Mapping Improvements
Summary Improvements have been made to how Nessus plugins determine the active version of Oracle Enterprise Manager Agent. How Patch Mapping Works for Oracle Enterprise Manager Agent Scans Prior to these improvements, the Enterprise Manager Agent version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including Enterprise Manager Cloud Control and Agent, are enumerated in one of two possible ways: Linux Local Detections: oracle_enum_products_nix.bin (plugin ID 71642, requires SSH credentials) Windows Local Detections: oracle_enum_products_win.nbin (plugin ID 71643, requires SMB credentials) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 86575 (oracle_enterprise_manager_agent_installed.nbin) reports only the base version (e.g 13.5.0.0.0). The full version (patch level) is determined, processed for the relevant vulnerabilities and reported in the individual vulnerability plugins (e.g plugin ID 192753), again by referencing a Tenable managed mapping table. Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out of band cycle or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 13.5.0.0.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on the mapping tables. Plugin ID 86575 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping tables are still checked, and a version comparison is performed to determine the highest patch level present. For Enterprise Manager Agent, the vulnerability plugins like 192753 will no longer need to determine for themselves the installed version (patch level), as this will now be done via the underlying detection plugin, 86575. This plugin will now also report all of the installed patches for the ORACLE_HOME in which the detected Enterprise Manager Agent product resides. Expected Impact Improved accuracy in version detections for Oracle Enterprise Manager, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins - 86575 - oracle_enterprise_manager_agent_installed.nbin - All Oracle Enterprise Manager Agent local vulnerability check plugins (e.g 192753) Targeted Release Date - Wednesday, July 2, 2025Research Release Highlight - Changes to SMB Kerberos
Research Release Highlight - Changes to SMB Kerberos Summary Kerberos has been the default authentication mechanism for domain connected Windows devices since Windows 2008. Tenable credentialed scans of Windows targets support an explicit Kerberos credential type. The explicit credential, which names the DC and domain name, frees the Nessus sensor from having to be connected to the Windows domain being scanned and allows the scanner to be hosted on Linux or MacOS as well. The nature of this explicit Kerberos credential type has widely led to the expectation that a Kerberos scan of Windows will never use NTLM. That is not true. Currently Kerberos Windows scans will fail over to using NTLM if Kerberos does not succeed. The Kerberos protocol depends on time synchronization, FQDN target specification and bi-directional DNS name resolution, but NTLM does not. Tenable fails over to NTLM to preserve scan continuity where Kerberos on the target or scanner may not be configured correctly. As each Windows credential is tried, if Kerberos fails, a second attempt will be made using NTLM. Change We are changing Windows scans so that a scan will try all Windows credentials first before trying them again using NTLM if the credential set contains at least one Kerberos credential. This change also extends our Kerberos coverage to include Windows Configuration Manager and Active Directory Service Interfaces (ADSI) scans. Impact In certain customer environments where a single service credential (username/password) is used across multiple domains the current failover behavior causes NTLM to be used prematurely when it is possible that a subsequent Kerberos credential targeting a different domain might succeed. The change here favors Kerberos first and only fails over to NTLM after all credentials have been tried. Customers can also modify their SCCM (Windows Configuration Manager) credentials to include the domain controller's FQDN to allow those scans to use Kerberos. The net effect of these changes will be reduced dependency on NTLM in Windows scans and should produce better results in some cases. Target Release Date 07/16/2025
