v3.5.1-R2.2 installer executable flagged by multiple security scanners. Can installer security be improved?

[vixelfox]

Installer gets a very poor score (high confidence malicious) on both Filescan and Hybrid-Analysis. Is there any way to remove unnecessary API imports or change the way bundled resources are delivered to avoid triggering these malware scans?

Or to continue to provide the zip versions for manual install?

https://www.filescan.io/uploads/664cbf69e25d7eb304f965b6/reports/e1485208-0b06-444d-b09a-54d8c31edef7/overview

https://hybrid-analysis.com/sample/2044f8ae73e6f8facf6f0a2b3db4bc09d083159ad75361615dc24e8b17b45b99/664c8cb2c2de56ba5b0d03ca

[RyanMetcalfeInt8]

I'm open to any kind of suggestions around improving security.

I'm not sure what kind of 'unnecessary API imports' you're referring to, but our Inno Setup script is here (https://github.com/intel/openvino-plugins-ai-audacity/blob/main/tools/windows/audacity_ai_plugins.iss) in case you want to help take a look.

Bundling everything as zip files was okay for the R1 release, but wasn't / isn't a scalable approach, as the number of supported models increased. Even with R1's zip file method, I had a ton of users file issues that things were working due to mistakes in putting the files in the right place.

[vixelfox]

I took a look at the Inno Setup script and queried Google's Gemini about some of the flagged stuff.

Some of the behaviors seem normal for an installer (manipulate threads and memory, write data to a remote process, query local/system time as file time) and detection sandboxes could trigger false positives if they didn't account for this.

According to Gemini, it's uncommon for portable executables (PE) to have embedded PE as resources and Inno Setup doesn't typically create PE with embedded PE directly. In legitimate cases an embedded PE may be a compressed 32/64 bit version of an application that ships with a self-extractor, or a helper binary, or optional plugins that are standalone executables. In malicious cases it's a way to obfuscate malware or evade antivirus security checks. I don't have additional commentary besides suggesting to review the installation approach at a high level and see if there's a cleaner way to manage complexity vs embedding PE in a PE.

(Hybrid-Analysis) For the icon with unusual entropy in embedded PE audacity-win-v3.5.1-R2.2-64bit-OpenVINO-AI-Plugins.tmp, the entropy could be caused by a custom icon made in an uncommon format, or it could be a false positive if the whole PE including the icon section is packed/encrypted at scan-time. However, unusual entropy could also indicate malware or packed/encrypted executables. Maybe experiment with no icons/new icons in a build and see if the flag disappears.

(Hybrid-Analysis) For the API call to GetKeyState with nVirtKey parameters in embedded PE audacity-win-v3.5.1-R2.2-64bit-OpenVINO-AI-Plugins.tmp, this behavior doesn't seem normal and could imply a keylogger. I'm not familiar enough with the audacity plugins or generated installer to know if there's any point where there's a Press Any Key to Continue type dialogue. If there is such a dialogue, maybe the problem could be re-designed away.

(Hybrid-Analysis) For the mismatched CRC in _setup64.tmp, this doesn't seem normal. It suggests file corruption or tampering. There are tools that could help verify CRCs, like RapidCRC and 7-Zip, which might assist in locating the offending file.

(Filescan) The API calls to:

• AdjustTokenPrivileges@advapi32.dll
• GetTokenInformation@advapi32.dll
• LookupPrivilegeValueW@advapi32.dll
• OpenProcessToken@advapi32.dll
• ExitWindowsEx@user32.dll

are not common unless installing something like system-wide drivers. It's best practice to follow a least-privilege approach and only use them if absolutely necessary. Inno Setup doesn't generate installers that reference any of the listed APIs for standard installations. The issue could be from something in the [Code] section of the Inno Setup script. To troubleshoot, maybe try a build without [Code] in the Inno Setup script and see if it still gets flagged.

Something in one of the PE is making an API reference to ExitWindowsEx@user32.dll, which could be used to shutdown or lock the system. What would be the purpose of calling this API / managing the system power state? If nothing in the installer code or plugin code needs this API, it may be worth exploring if there's any way to avoid referencing it. Here is the full list of API imports from user32.dll according to filescan.io in case it helps track down what code might be the culprit:

CreateWindowExW TranslateMessage CharLowerBuffW CallWindowProcW CharUpperW PeekMessageW GetSystemMetrics SetWindowLongW MessageBoxW DestroyWindow CharUpperBuffW CharNextW MsgWaitForMultipleObjects LoadStringW ExitWindowsEx DispatchMessageW

[RyanMetcalfeInt8]

Hi @vixelfox,

Thanks, but to be honest I don't really know what to make of this information. What changes do I need to make to the Inno Setup script?