We have paused updating of AIMP until further notice.
2026/04/26: Microsoft Defender reports x64 installer infected with:
Trojan: Win32:Wacatac.H!ml
We have paused updating of AIMP until further notice.
2026/04/26: Microsoft Defender reports x64 installer infected with:
Trojan: Win32:Wacatac.H!ml
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.
Create a Custom Software configuration containing:
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:

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:

Once your deployment job is created and executed on hosts, contact Support.
We will enable a background cron job that:
The background job can run up to once per hour.
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.
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.
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.
This mechanism allows you to:
If you have questions or want help setting this up, feel free to reach out to Support.
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:
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.
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.
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.
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
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
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
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
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
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.
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.
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.
It appears that Adobe released version 25.001.20756 yesterday, however, it is not yet accompanied by release notes, we advice that you upgrade to 25.001.20756 on a few hosts and test this, before upgrading on a large scale.
We are currently testing this upgrade, and will release it once it passes the regular testing.
While reviewing detection for Avast Free Antivirus and Avast Business Security, we were unable to find reliable information confirming whether the following vulnerabilities have been fixed:
CVE-2025-3500
https://www.zerodayinitiative.com/advisories/ZDI-25-256/
This ZDI advisory specifies a fix; we have decided to rely on this information.
CVE-2024-7227
https://www.zerodayinitiative.com/advisories/ZDI-24-1003/
We have found no public documentation that this privilege-escalation vulnerability has been fixed.
Therefore, we have flagged both Avast Free Antivirus and Avast Business Security as Untracked. If no fixes are documented soon, we may escalate this status to Insecure / 0-day.
@OLLI_S This should have been solved on 2nd December, can you confirm?
And thank you for reporting it.
During testing of the Google Chrome 131.0.6778.109 MSI package, we found that it was broken, resulting in Exit Code 1603 after attempting to spawn a UAC prompt as the SYSTEM user.
This issue occurs both when upgrading via VulnDetect and Intune. In some cases, it even breaks the existing installation during rollback of the failed update.
As a result, we pulled the update before releasing it to customers.
Once Google has fixed the Enterprise "ready" MSI installer, we will update the package and make it available after thorough testing.
Please "upvote" the following post by Mikhail Gurin if you are affected by this and have a Google account. Hopefully, this will help make Google prioritize the fix: https://support.google.com/chrome/thread/311347547
For reference, we use the following installers:
https://dl.google.com/tag/s/dl/chrome/install/googlechromestandaloneenterprise.msi
https://dl.google.com/tag/s/dl/chrome/install/googlechromestandaloneenterprise64.msi
We also tested the EXE-based installers for offline deployment but found that these are incompatible with MSI-based installations.
It should be noted that the MSI works if launched interactively as a regular user who can approve the UAC prompt.
Can I uninstall the Agent using the Agent and Custom Software?
Yes, that is doable, although you won't be able to see the correct state in the Job Activity, because the system won't be able to report back to the backend.
Here is a PowerShell script that does that:
$SecTeer = "SecTeer VulnDetect"
$PF = if ([Environment]::Is64BitOperatingSystem) { ${env:ProgramFiles(x86)} } else { $env:ProgramFiles }
$SecTeerPath = Join-Path $PF $SecTeer
$unins = @("unins000.exe","unins001.exe") | ForEach-Object { Join-Path $SecTeerPath $_ } | Where-Object { Test-Path $_ } | Select-Object -First 1
$ok = $true
if($unins){
$p = Start-Process -FilePath $unins -ArgumentList "/VERYSILENT /SUPPRESSMSGBOXES /FORCECLOSEAPPLICATIONS /NOCANCEL" -Wait -PassThru -WindowStyle Hidden -ErrorAction SilentlyContinue
if(!$p -or $p.ExitCode -ne 0){ $ok = $false; Write-Warning "Uninstaller exit code: $($p.ExitCode)" }
}else{
$app = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall","HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" -ErrorAction SilentlyContinue |
Get-ItemProperty -ErrorAction SilentlyContinue | Where-Object DisplayName -Like "$SecTeer*"
foreach($a in $app){
if($a.UninstallString -match 'MsiExec\.exe.*?({[\w-]+})'){ Start-Process msiexec.exe "/x $($matches[1]) /qn /norestart" -Wait -ErrorAction SilentlyContinue }
elseif($a.UninstallString){ Start-Process cmd.exe "/c $($a.UninstallString) /qn /norestart" -Wait -ErrorAction SilentlyContinue }
}
}
Get-ScheduledTask -ErrorAction SilentlyContinue | Where-Object { $_.TaskName -like "SecTeer VulnDetect*" -or $_.TaskName -like "SecTeerVulnDetect*" } |
ForEach-Object { Unregister-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath -Confirm:$false -ErrorAction SilentlyContinue }
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall","HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" -ErrorAction SilentlyContinue |
Where-Object { (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).DisplayName -like "$SecTeer*" } |
Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item (Join-Path $env:ProgramData $SecTeer) -Recurse -Force -ErrorAction SilentlyContinue
if($ok){ Write-Output "$SecTeer removed."; exit 0 } else { Write-Warning "$SecTeer uninstall may have failed."; exit 1 }
Thank you for reporting this. I believe it is fixed now. But I failed to find an account that belongs to you with this app, so I didn't double check that it works.
Note that it requires a new inspection.
Version 3.4.0.0 is the latest Stable release.
It can be downloaded from here:
https://vulndetect.com/dl/agents/secteerSetup-3.4.0.0.exe
https://vulndetect.com/dl/agents/secteerSetup-3.4.0.0.msi
Based on customer requests we've examined ways to update Portable Apps, like apps form the SysInternals bundle.
There are many ways to achieve this, but we wanted one that works well with the Custom Software feature in VulnDetect.
We also wanted to avoid making one Config per App in the SysInternals bundle.
And, since these files can live in various places, including folders that are writable by non-privileged users, we wanted to be careful not to overwrite the wrong files or follow symbolic links.
The script will not overwrite files unless they have the company name specified in the $companyNameToCheck variable, it will also not touch files in the $excludedDirs.
The combination of Custom Software and this script assumes that you add a ZIP archive as an Additonal File and that the ZIP archive contains a folder called "files" with all the SysInternal files you want to replace, e.g. the entire SysInternals bundle.

You can also edit the $sourceDir variable if you want to use a different layout in your ZIP archive.
The below script was created by ChatGPT (by OpenAI). It was created based on the above requirements and it has been reviewed and tested by SecTeer.
Note: This script is intended to run in an automated fashion and with a sub folder of known trusted files. Executing this in the wrong location and altering variables and conditions may have unforeseen consequences, because the script overwrites files recursively.
# Define the company name to check for
$companyNameToCheck = "Sysinternals - www.sysinternals.com"
# Get the current working directory and set the source directory to the "files" subfolder
$sourceDir = Join-Path -Path (Get-Location) -ChildPath "files"
$drive = "C:\"
# List of directories to exclude (common shim file locations)
$excludedDirs = @(
"$env:SystemRoot\AppPatch",
"$env:SystemRoot\System32\ShimCache"
)
# Function to get the latest file from a directory
function Get-LatestFile {
param (
[string]$directory,
[string]$fileName
)
$files = Get-ChildItem -Path $directory -Filter $fileName
$latestFile = $files | Sort-Object LastWriteTime -Descending | Select-Object -First 1
return $latestFile
}
# Function to check the "Company Name" and "Product Name" properties of a file
function Get-FileProperties {
param (
[string]$filePath
)
$properties = Get-ItemProperty -Path $filePath -Name 'VersionInfo'
return @{
CompanyName = $properties.VersionInfo.CompanyName
ProductName = $properties.VersionInfo.ProductName
}
}
# Function to recursively replace files in the target directory with the latest from the source directory
function Replace-Files {
param (
[string]$sourceDir,
[string]$drive,
[string]$companyNameToCheck
)
# Get the list of files in the source directory
$sourceFiles = Get-ChildItem -Path $sourceDir
# Iterate over each file in the source directory
foreach ($sourceFile in $sourceFiles) {
# Get the latest version of the source file
$latestSourceFile = Get-LatestFile -directory $sourceDir -fileName $sourceFile.Name
# Find matching files in the drive recursively, excluding the source directory and excluded directories
$matchingFiles = Get-ChildItem -Path $drive -Filter $sourceFile.Name -Recurse -ErrorAction SilentlyContinue | Where-Object {
$_.FullName -notlike "$sourceDir*" -and
$excludedDirs -notcontains $_.DirectoryName
}
# Replace each matching file with the latest source file if the company name matches and it is not a Chocolatey shim file
foreach ($targetFile in $matchingFiles) {
$properties = Get-FileProperties -filePath $targetFile.FullName
if ($properties.CompanyName -eq $companyNameToCheck -and $properties.ProductName -notlike "*Chocolatey Shim*") {
Copy-Item -Path $latestSourceFile.FullName -Destination $targetFile.FullName -Force
Write-Output "Replaced $($targetFile.FullName) with $($latestSourceFile.FullName)"
} else {
Write-Output "Skipped $($targetFile.FullName) as it is either not from '$companyNameToCheck' or it is a Chocolatey shim file"
}
}
}
}
# Call the function to replace files
Replace-Files -sourceDir $sourceDir -drive $drive -companyNameToCheck $companyNameToCheck
@OLLI_S There are a few users, yes.
The website doesn't really state anything at all:
https://pcmanager.microsoft.com/en-us
I'll leave it as Untracked and Pre-release for now, do let me know if you see some official statement that I can link to and then we'll flag the EXE edition as EoL.
@OLLI_S From what I can see, then detection of Rufus and SumatraPDf is working as expected. As you know, part of our detection relies on the original filenames, so when an app or user renames EXE files, it easily (and intentionally) bypasses our detection.
Is FileZilla a standard sub application of Cygwin?
Perhaps we should bundle it?
@OLLI_S We actually stopped bundling it a long time ago. When I look at your results, then I see all the 365 Apps.
There are two reasons we stopped bundling it. One is that Microsoft frequently releases unknown builds to a subset of systems, this breaks some logic that we rely upon. The other is that the Suite system doesn't support packages, so in order to support updating 365 Apps, we had to stop using the Suite bundle.
We may change this eventually, but it's not on the roadmap at the moment.
Btw. if some of your 365 Apps disappear, then it may be because you ran into one of those Unknown builds, please ping me directly, next time you only see some of them, then I can verify whether this is the reason.
@OLLI_S Yes, I can see they changed some properties. It should be fixed now.
Thank you for reporting this.