Global Moderators group | VulnDetect - An alternative to the End-of-Life Secunia PSI and SUMo / DUMo

Tom

@OLLI_S Can you try inspecting again.

Tom

Why we only patch the two most recent major Python versions

Python follows a lifecycle where only the newest major versions receive full support, including official binary installers. Once a version moves into security-fix-only mode, upstream stops shipping these installers.

From Python 3.12 release notes:

“Python 3.12 is now in the ‘security fixes only’ stage… releases of those are made irregularly in source-only form... binary installers are no longer provided.”

Source:
https://www.python.org/downloads/release/python-31213/

For older versions:

Updates are source-only, not packaged installers
No consistent or supported upgrade path on Windows
Effectively shifts maintenance to manual builds or downstream distributions

Bottom line:
If upstream doesn’t ship a proper installer, we don’t have a reliable or safe way to patch it.

Tom

We have paused updating of AIMP until further notice.

2026/04/26: Microsoft Defender reports x64 installer infected with:
Trojan: Win32:Wacatac.H!ml

Tom

How to automate tag assignments based on host facts

This guide explains how you can automatically assign VulnDetect tags based on information collected directly from hosts - such as hardware details, OS version, Intune enrollment status, and other system facts.

The approach uses a PowerShell script executed through a Custom Software deployment. The script gathers host information and outputs structured data that our backend service reads and converts into tags.

Overview

A PowerShell script runs on hosts using Custom Software deployment.
The script collects system facts and outputs JSON.
A background job processes that output and creates or assigns tags automatically.

Step 1 - Create a Custom Software configuration

Create a Custom Software configuration containing:

The assignMyTags.ps1 script
The functions.ps1 helper script
(these scripts are provided as examples, to show how the output should look like, please adjust to your needs).

The configuration must be named with the following prefix:

assignMyTags: <something>

Example:

assignMyTags: hardwareFacts

The prefix is required because the backend automation looks for deployments using this naming pattern.

Custom Deployment Configuration:

Step 2 - Create a Deployment Job

Create a deployment job using the Custom Software configuration.

The deployment job must be named with this prefix:

Custom deployment assignMyTags: <something>

Example:

Custom deployment assignMyTags: hardwareFacts

The backend job relies on this prefix to locate the deployment results.

Custom Deployment Job:
Create Custom Deployment Job assignMyTags.png

Step 3 - Contact Support

Once your deployment job is created and executed on hosts, contact Support.

We will enable a background cron job that:

retrieves the script output
creates any missing tags
assigns the tags to the relevant hosts

The background job can run up to once per hour.

Tag naming recommendations

You are free to choose your own tag names, but we recommend using a clear prefix so automated tags are easy to identify.

Example:

auto.cpu-model: Intel Core i7-1260P
auto.tpm-version: 2.0
auto.laptop-model: ThinkPad T14 Gen 3

Only certain characters are allowed in tag names. Any unusual characters will automatically be removed by the background script.

Versioning tags

Inside the PowerShell script you will find two settings:

$amtName
$amtVersion

Example:

$amtName = "hardwareTags"
$amtVersion = "2"

These values control tag generations.

When the version number is incremented, the backend automation will automatically remove older tags with the same name.

This makes testing easier and prevents duplicate or outdated tags from accumulating.

Example workflow:

hardwareTags v1
-> test
-> change script
-> hardwareTags v2
-> old v1 tags automatically removed

The version must be an integer.

Updating dynamic tags

If your tags represent dynamic values (for example Intune enrollment status or disk encryption state), we can also help configure periodic redeployment of the Custom Software job.

This allows the host facts to be refreshed regularly so tags remain accurate over time.

Contact Support if you would like to enable this.

Summary

This mechanism allows you to:

Automatically tag hosts based on real system data
Maintain consistent tagging across your environment
Easily iterate and test tag definitions using versioning
Keep tags updated through scheduled deployments

If you have questions or want help setting this up, feel free to reach out to Support.

Tom

The reported Notepad++ supply-chain incident, as described in public reporting, was limited to the application’s built-in auto-update mechanism.

SecTeer VulnDetect does not use or depend on the Notepad++ auto-updater. All Notepad++ packages distributed through SecTeer are downloaded directly from the official vendor source and processed through SecTeer’s own validation pipeline.

This includes:

Verification of the Authenticode signature where the vendor provides signed binaries
Malware scanning using Microsoft Defender
Additional reputation-based checks as a supplementary control

SecTeer packages are released independently of the vendor’s auto-update channel and are not delivered through the update mechanism involved in the reported incident. As a result, SecTeer did not distribute compromised code, and SecTeer’s distribution infrastructure was not impacted.

A system could only have received the compromised update if the built-in Notepad++ auto-update feature was enabled on the system

In short: SecTeer’s update mechanism was not involved in the incident, and no compromised Notepad++ packages were delivered through the SecTeer platform.

arbk

Advanced customization: TeamViewer install + assignment (PatchPro / VulnDetect)

This approach is for customers who want to run a PowerShell script as the installer (instead of running the MSI/EXE directly). The script installs TeamViewer from an MSI placed in the same working directory and then runs a TeamViewer assignment command.

Important: the PowerShell script MUST be the primary installer. The MSI must be included as an additional file.

PatchPro Instructions
1. Create a new text document containing the script below.
2. Save the file as a PowerShell script (.ps1), e.g.:
TVInstallAndAssign.ps1
3. Navigate to Available Applications and select TeamViewer 15 (x64) (MSI).
4. Click Custom Publish.
5. Click the downward arrow next to the Browse icon to move the TeamViewer installer into Additional Files.
6. Click the Browse icon and select your .ps1 script.
7. Remove any custom installer arguments like /qn /norestart (the script handles msiexec arguments).
8. Give the deployment a name and click Publish.

VulnDetect - Advanced Customization Instructions

This method uses a PowerShell script as the installer. The script installs TeamViewer from an MSI placed in the working directory and then performs the assignment.

The PowerShell script must be the installer. If it is not moved into the installer position, it will not execute.
1. Create a new text document containing the script below.
2. Save the file as a PowerShell script (.ps1), for example:
TVInstallAndAssign.ps1
3. Navigate to Approvals and edit the desired Tag Approval.
4. Move the TeamViewer installer down using the blue arrow button.
5. Click Choose File and select your .ps1 script (this must be the installer).
6. Remove any installer arguments (these are handled by the PowerShell script).
7. Click Save.

Prerequisites (read this)
• The script expects the TeamViewer MSI to be included as an Additional File in the same working directory as the script.
• MSI exit code 3010 is treated as success (reboot required) and will be returned as the script exit code.
• The script fails if assignment does not complete successfully (non-zero exit code or timeout).
• Replace the assignment id/token placeholder before publishing.
Note: The assignment method varies depending on license type, this is just an example for a specific license type.

# # ==========================================
# SecTeer: TeamViewer Install (MSI) + Assignment
# ==========================================

$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path

$LogFolder = "C:\Windows\Logs\SecTeer"
$LogFile   = Join-Path $LogFolder "TeamViewer-assign.log"

# --- Ensure log folder exists ---
if (-not (Test-Path $LogFolder)) {
    New-Item -Path $LogFolder -ItemType Directory -Force | Out-Null
}

function Write-Log {
    param([string]$Message)
    "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] $Message" |
        Out-File -FilePath $LogFile -Append -Encoding UTF8
}

Write-Log "Script started"

# --- CONFIG: assignment token (MUST be replaced before deployment) ---
$AssignmentArgs = 'assignment --id REPLACE_WITH_REAL_ASSIGNMENT_TOKEN'

# Fail fast if placeholder still present
if ($AssignmentArgs -match 'REPLACE_WITH_REAL_ASSIGNMENT_TOKEN') {
    Write-Log "ERROR: Assignment token placeholder not replaced. Aborting."
    exit 1
}

# --- Locate MSI next to this script (supports .msi and .msi.msi) ---
$MsiMatches = Get-ChildItem -Path $ScriptDir -File |
    Where-Object { $_.Name -match '^TeamViewer.*\.msi(\.msi)?$' }

if (-not $MsiMatches -or $MsiMatches.Count -eq 0) {
    Write-Log "ERROR: No TeamViewer MSI found in $ScriptDir"
    Get-ChildItem -Path $ScriptDir -File | ForEach-Object {
        Write-Log "Found file: $($_.Name)"
    }
    exit 1
}

if ($MsiMatches.Count -gt 1) {
    Write-Log "ERROR: Multiple TeamViewer MSI files found:"
    $MsiMatches | ForEach-Object { Write-Log " - $($_.FullName)" }
    exit 1
}

$MsiPath = $MsiMatches[0].FullName
Write-Log "Using MSI: $MsiPath"

# --- Install TeamViewer ---
Write-Log "Starting TeamViewer MSI installation"

$msiArgs = "/i `"$MsiPath`" /qn /norestart"
$msiProc = Start-Process -FilePath "$env:WINDIR\System32\msiexec.exe" `
    -ArgumentList $msiArgs `
    -Wait `
    -NoNewWindow `
    -PassThru

$msiCode = [int]$msiProc.ExitCode
Write-Log "MSI exited with code: $msiCode"

# Accept 0 (success) and 3010 (success, reboot required)
if ($msiCode -ne 0 -and $msiCode -ne 3010) {
    Write-Log "ERROR: MSI installation failed"
    exit $msiCode
}

# --- Allow post-install finalization ---
Start-Sleep -Seconds 10

# --- Locate TeamViewer executable ---
$TvExeCandidates = @(
    "C:\Program Files\TeamViewer\TeamViewer.exe",
    "C:\Program Files (x86)\TeamViewer\TeamViewer.exe"
)

$TvExe = $TvExeCandidates | Where-Object { Test-Path $_ } | Select-Object -First 1

if (-not $TvExe) {
    Write-Log "ERROR: TeamViewer executable not found"
    $TvExeCandidates | ForEach-Object { Write-Log "Checked: $_" }
    exit 1
}

Write-Log "Using TeamViewer executable: $TvExe"

# --- Assignment ---
Write-Log "Starting TeamViewer assignment"
Write-Log "Executing: `"$TvExe`" $AssignmentArgs"

$tvProc = Start-Process -FilePath $TvExe `
    -ArgumentList $AssignmentArgs `
    -PassThru `
    -NoNewWindow

$TimeoutMs = 120000
if (-not $tvProc.WaitForExit($TimeoutMs)) {
    Write-Log "ERROR: Assignment timed out after $([int]($TimeoutMs/1000)) seconds"
    try { $tvProc.Kill() } catch {}
    exit 1
}

$tvCode = [int]$tvProc.ExitCode
Write-Log "Assignment exited with code: $tvCode"

if ($tvCode -ne 0) {
    Write-Log "ERROR: TeamViewer assignment failed"
    exit $tvCode
}

Write-Log "TeamViewer installation and assignment completed successfully"

# Per requirement: propagate installer exit code
exit $msiCode

Tom

We have started recommending version 1.3.301 due to reports from Customers about failed upgrades when deploying version 1.3.304. This appears to be related to a bug in the installer where upgrading while Greenshot is running can cause the existing install to be removed or fail. You can review the specific issue here:

https://github.com/greenshot/greenshot/issues/732

We will update the Greenshot package when a new version is released.

Tom

Custom Software & Advanced Customisation - Technical Usage Guide

These features allow you to deploy Windows installers and supporting files to any Windows device.
Both features work the same way operationally; Advanced Customisation ties into our version-based detection for supported applications.

What the System Does

Execution Context

Each job runs either as SYSTEM or as the logged-in user.
Advanced Customisation automatically selects the correct context for the target app.

All uploaded files are placed into a temporary working directory controlled by our package wrapper. This directory is cleaned up automatically after execution.

Primary Installer vs. Additional Files

Primary Installer

Only the primary installer is executed.

Supported primary file types:
• .msi
• .msp
• .exe
• .ps1
• .bat
• adobe*.zip (special handling; primary only)

You can supply arguments for the primary installer.

Additional Files

Additional files are placed in the working directory but are not executed automatically.

Typical uses:
• Transforms/configs (.mst, .cfg, .xml)
• Supporting content (.zip, .ini, etc.)
• Registry files (.reg)

If a secondary file must be executed, make the primary file a script and orchestrate everything from there.

Example using .mst:
https://vulndetect.org/topic/2382/foxit-phantompdf-to-foxit-pdf-editor-upgrade

File-Type Behaviour

MSI / MSP / EXE

Executed using the arguments you provide.
All standard environment variables behave as expected for the chosen context (SYSTEM/user).

Example:
https://vulndetect.org/topic/2540/openvpn-install-upgrade
https://vulndetect.org/topic/2382/foxit-phantompdf-to-foxit-pdf-editor-upgrade

Scripts (.ps1, .bat)

Executed as the primary installer.
Scripts run under PowerShell 5.1 or CMD.
If a restricted PowerShell language mode is enforced, execution will fail.

Example:
https://vulndetect.org/topic/2386/running-powershell-scripts

REG Files (.reg)

Automatically imported using:

reg import filename.reg

No additional processing is performed.

Example:
https://vulndetect.org/topic/2388/registry-files-and-the-custom-software-feature

ZIP Files

General ZIP Files
Extracted automatically into the working directory.
Nothing is executed automatically — your script/installer must make use of the extracted content.

Adobe ZIP Archives (adobe*.zip)
When the primary file matches adobe*.zip, the system will:
1. Extract the archive using 7-Zip
2. Locate the Adobe setup installer
3. Execute it automatically

The ZIP must be the unmodified package downloaded from the Adobe Creative Cloud portal.

Example:
https://vulndetect.org/topic/2385/adobe-creative-cloud-install-upgrade

Working Directory

All uploaded files — primary and additional — are placed in the same temporary folder.

Relative references such as:

myconfig.xml
.\transform.mst

work normally.

Subfolders are not created unless your installer or script creates them.

Example:
https://vulndetect.org/topic/2621/install-autocad-lt

Detection & Success Criteria

Custom Software
• Accepted success codes: 0, 3010, 1603
• No version-based detection
• Exit codes only determine whether a reboot is required

Advanced Customisation
• Version-based detection tied to the application’s Recommended Version
• Whitelisted success/reboot codes (varies per app)
• More reliable detection overall

Common Use Cases

MSI with transform/config

Primary: myapp.msi
Additional: custom.mst, config.xml
Arguments:

msiexec /i myapp.msi TRANSFORMS=custom.mst /qn

Script orchestrating secondary actions

Primary: install.ps1
Additional: payload.zip, settings.reg
The script handles extraction, registry import, and any secondary execution.

Adobe Creative Cloud package

Primary: adobe-designteam.zip
The ZIP is extracted automatically and the internal Adobe setup installer is executed.

Installer requiring bundled resources

Primary: setup.exe
Additional: resources.zip
The ZIP is extracted automatically; your installer must reference the extracted content.

Operational Notes
• Only the primary installer receives arguments.
• Use a script as the primary file for multi-step processes.
• Execution context provides standard environment variables (similar to Task Scheduler).
• PowerShell 5.1 is always available; restricted modes will break the wrapper.

Tom

Today we received a number of reports about issues with Adobe Acrobat / Reader DC Continuous about it failing to start with the error: “Acrobat failed to load its Core DLL” after updating to version 25.001.20982.

This is caused by a faulty Adobe update and is not related to VulnDetect.

Shortly after receiving the first report, we changed the Recommended version to the previous one, thus effectively stopping new update tasks from being created.

Based on customer feedback and claims on various forums, it seems that installing the same architecture of the Microsoft Visual C++ 2015–2022 Redistributable as the installed Adobe Acrobat / Reader fixes the issue (for most). There are also reports that a full uninstall and reinstall of the previous version is required.

If in doubt, deploy the VC++ package first - it solves the issue for the majority.

You can do both things using SecTeer VulnDetect by using Tags and Deployment Jobs.

Adobe Acrobat Reader DC Continuous (x32)
https://corporate.vulndetect.com/#/applications/hosts?channelTag=adobe.acrobatreaderdc.default&title=Adobe Acrobat Reader DC Continuous (x32)

Adobe Acrobat Reader DC Continuous (x64)
https://corporate.vulndetect.com/#/applications/hosts?channelTag=adobe.acrobat.reader.dc&title=Adobe Acrobat Reader DC Continuous (x64)

Adobe Acrobat DC Continuous
https://corporate.vulndetect.com/#/applications/hosts?channelTag=adobe.acrobat.default&title=Adobe Acrobat DC Continuous

Note: Due to the way we detected Reader vs. Acrobat initially, and the way Adobe decided to handle 64-bit Reader, we ended up with architecture-specific detections for Reader, whereas Acrobat still covers both 32/64-bit.

On each of these links, you should select the hosts you need to “fix” and click Manage Tags for Selected Hosts, then assign a new tag that indicates the need to install the Visual C++ 2015–2022 Redistributable.

Under Deployment:
https://corporate.vulndetect.com/#/deployment/create-job

You should select Microsoft Visual C++ 2015–2022 Redistributable as appropriate and click Configure Deployment Job With X Application, then Select Tags, Groups or Hosts, find the newly created tag, click Set Job Name, adjust as you see fit, and finally click Create Deployment Job.

To speed up the deployment, you may want to go to Tags:
https://corporate.vulndetect.com/#/tags

Then click X Hosts and select as many hosts as you wish to initiate deployment to immediately. Note that clicking Inspect and Update Selected Hosts will initiate the deployment on all online hosts within a few minutes.

If you need to roll back Adobe Acrobat / Reader, you can also use Tags in a similar way to create a Deployment Job that uninstalls Adobe Acrobat / Reader, and then create a new one which installs it. Ensure that the Uninstall Job is set to “Install or uninstall once” and that it is attempted before you assign the Install Job. The Install Job may be set to “Always install or uninstall.”

Once Adobe publishes a fixed build, we will set it as the Recommended version so upgrades resume automatically.

Tom

The release notes are out:
https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/continuous/dccontinuoussept2025qfe.html#dccontinuoussepttwentytwentyfiveqfe

This is the official fix for the printing issue:

4529876: Data loss in printing PDF on Reader and Acrobat

The packages for Acrobat/Reader in VulnDetect and PatchPro was released earlier this morning.