, ,

, , , , , , ,

CVE-2024-30376 Unpatched: Advanced IP Scanner still ships a Qt LPE in the same build that leaks NTLM

By Javier Medina ( X / LinkedIn)

TL;DR

Two days ago we published our write-up on CVE-2025-1868, showing how Advanced IP Scanner can leak NTLM challenge-response material during routine scans, and how it remains unpatched nine months later.

That post got shared on r/InfoSecNews, and one short comment from BladeCollectorGirl made us doubt:

Used to be one of the best Windows scan tools… I’ve stopped using it a few years ago because of security issues.

The next thing we landed on was CVE-2024-30376 (ZDI-24-670). This is a local privilege escalation condition where Advanced IP Scanner loads Qt plugins from an unsecured location, enabling low-privileged users to pre-stage a path and have code executed when an admin later runs the tool.

The post focuses on operational impact, lab validation and defender guidance.

Details for Busy People

  • ZDI disclosed this as a 0-day in June 2024 after reporting it to the vendor in May 2023
  • NVD’s details that the application loads Qt plugins from an unsecured location
  • The problem originates in an old Qt issue from 2022 that allows privilege escalation due to the hardcoding of the qt_prfxpath value
  • Two years later, the affected binaries are still being distributed, turning any installation of the tool into a potential vector for local privilege escalation.
  • LPE requires local standard-user access to the host (or malware running as user) and also requires an administrator to run Advanced IP Scanner elevated.
  • Impact depends on whether endpoints allow standard users to create the staged directory chain.
  • We have indications that Advanced Port Scanner is also affected for similar behavior.
  • The same current distributable build (2.5.4594.1) is tracked as affected by the Qt LPE (CVE-2024-30376) and is also within the affected range for the NTLM leakage (CVE-2025-1868).

1# CVE-2024-30376 in Practical Terms

CVE-2024-30376 is tracked by ZDI as ZDI-24-670 and mapped to CWE-427 (Uncontrolled Search Path Element). NVD describes that the flaw exists within the application’s use of Qt, and the application loads Qt plugins from an unsecured location.

This lands in a class of Windows deployment problems that has been understood for years in the Qt ecosystem. CERT/CC’s advisory on Qt’s qt_prfxpath behavior explains why Windows deployments can end up consulting paths that should never be part of a privileged plugin search, and why proper deployment tooling (for example windeployqt) matters because it can replace the embedded prefix path value and reduce exposure.

The result, when everything aligns badly, is predictable. The application attempts to resolve an add-on in a location that does not exist, and a user without privileges can create that location and provide the add-on first.

2# Exploitation Mechanics

On an affected host, exploitation is about one ugly Windows default and one predictable habit of admins.

A low-priv user notices the app searches for a Qt plugin in a path that does not exist. In many enviroments, a default Windows user can create directories under C:\; so the attacker simply creates the missing folder tree and drops a DLL where Qt will look for it. Later, an admin runs Advanced IP Scanner during routine troubleshooting and the tool loads the attacker-controlled DLL in the elevated context.

This is the brief and practical evidence of the problem:

$ strings Qt5Core.dll | grep "qt_prfxpath"
qt_prfxpath=C:/Build/Qt/5.6.3/build32/qtbase

It is important to note that the vulnerability CVSS is classified as User Interaction (UI) Required. But, from our point of view, user interaction required is meaningless here. The interaction is the admin doing normal admin work, and the staging step is something any low-priv user can do in seconds.

3# Lab Evidence

We reproduced the behavior in our lab environment by observing plugin resolution activity, identifying missing search paths, preparing the filesystem state as a low-privileged user, and confirming code execution when the application was later launched by an administrator.

Tested build: 2.5.4594.1

A recipe for crafting an exploit

To demonstrate the impact, we converted the missing path observations into a functional privilege escalation chain using basic Windows primitives:

  • Reconstruct the Build Path: We manually created the directory structure C:\Build\Qt\5.6.3\build32\qtbase\plugins\platforms, matching the hardcoded path the application queries.
  • Plant the Decoy: We placed the missing file (qwindows.dll) in that directory.
  • Chain the Payload: Instead of compiling a complex Qt plugin, we simply modified the import table of our qwindows.dll to force the loading of a secondary DLL where our actual payload resided.
  • Execution: When Advanced IP Scanner was launched, it loaded our decoy plugin, which immediately pulled in our payload.dll and executed calc.exe

4# How to Validate It in Your Environment

You can validate the risky condition without writing an exploit.

First, simply run Advanced IP Scanner under Procmon and focus on early startup and plugin/module activity. Look for path probes and repeated failures (“PATH NOT FOUND”) against C:\Build\Qt\... directory.

Later check whether standard users can create directory trees in the relevant locations on your endpoints. In many environments, creating new folders under C:\ is still possible for standard users, and that is enough to convert missing path into attacker-controlled path.

5# What You Should Do

Remove these tools and apply our prior suggestions

If a vendor keeps shipping administrative tooling with publicly documented issues and undefined remediation gaps, standardizing on alternatives is the pragmatic choice.

You need discovery tools that do not quietly expand your attack surface under routine use.

Later, apply our prior suggestion about secure use of this kind of tools.

Monitor the right signal

Beyond the issue with Famatech and its tools, this should prompt us to think about local privilege escalations. So, if you want detection that generalizes beyond this specific case, focus on behavior:

  • Elevated processes loading DLLs from unusual directories
  • Plugin discovery patterns that touch user-writable locations
  • Directory creation and subsequent module loads that form a staging chain

These are signals blue teams should monitor as a baseline.

Harden permissions

However, it’s not all about detection and response; the simplest thing you can do in this case is prevent. This LPE works because Windows still lets standard users create folders under C:\ in many environments.

That single default gives attackers a staging surface. Our best advice is treat this as a permissions problem, so where compatibility allows, lock down the root of C:\ so non-admin users cannot create arbitrary directory trees.

6# Closing

Here is the uncomfortable conclusion. The first part of this research showed a tool that can leak NTLM material onto the wire during routine discovery. This post shows a tool that can be turned into an elevated code loader through a search path mistake that has been publicly understood for two years.

When a vendor keeps distributing an administrative utility in that state, the correct response is not to debate scoring semantics or wait for a patch that may never arrive. Remove it from the trusted set, block it where you cannot remove it, and harden the host so standard users cannot create arbitrary directory trees under C:\. That single policy closes a staging surface that keeps feeding the same class of local privilege escalation chains across products.

Annexes

Unpatched Versions

On 2026-01-03, we retrieved the vendor-hosted installer and recorded reproducible identifiers (SHA256 + embedded FileVersion/ProductVersion). Installer still corresponds to the vulnerable build (Advanced IP Scanner 2.5.4594.1)

Retrieved (UTC)ProductDownload ArtifactSize (bytes)SHA256VersionAuthenticode statusSigner (Subject)Signer Issuer (CA)
2026-01-03T16:04:54ZAdvanced IP ScannerAdvanced_IP_Scanner_2.5.4594.1.exe2105067226d5748ffe6bd95e3fee6ce184d388a1a681006dc23a0f08d53c083c593c193b2.5.4594.1ValidCN=Famatech Corp., O=Famatech Corp., L=Road Town, C=VG, SERIALNUMBER=597325, …Symantec Class 3 Extended Validation Code Signing CA – G2

Disclosure Timeline

We did not originally report this vulnerability. This timeline is sourced from the ZDI advisory (ZDI-24-670) and provided for context. Our work focuses on lab validation, operational impact, and defender guidance.

  • 2023-05-12 — Reported to vendor (ZDI)
  • 2024-06-13 — Publicly disclosed (ZDI-24-670)
  • 2026-01-09 — LABS@ITRES Research on ZDI-24-670 is published

References