Using SecTeer VulnDetect, you have access to 2 different scan approaches:

• On-Demand Scanning
  From the VulnDetect GUI, you can easily create scan groups manually. The groups can then scan immediately.
• VulnDetect Agent – Single Mode
  The SecTeer VulnDetect Agent is a standalone executable file that can run as a local service. The agent can be configured to scan the system at regular intervals available under “configuration”.

Yes. SecTeer VulnDetect is designed to deploy standard and security patches that were found missing from the scan results. This integration of SecTeer VulnDetect allows network administrators to easily handle the entire vulnerability management life cycle.

No. SecTeer VulnDetect does not scan removable or network drives such as USB sticks or other types of removable drives.

The number of systems that can be scanned by SecTeer VulnDetect is dependent on the license that you have purchased from SecTeer. If you reach your license limit, deleting old systems from SecTeer VulnDetect will release the corresponding number of licenses. If you need additional licenses, please contact your SecTeer Sales Representative.

Although the login of concurrent sessions is possible, SecTeer VulnDetect is designed to allow only one session per account. If you wish to have several SecTeer VulnDetect accounts, please ask your SecTeer Sales Representative about an additional Admin license.

The SecTeer VulnDetect Agent can be downloaded from your Dashboard under “configuration”.

You can reset your password by clicking on the link below:
https://vulndetect.com/#/forgot-password

If you still encounter issues, please contact support at: support@secteer.com

SecTeer VulnDetect is capable of scanning any Windows system, virtual machine and terminal server.

By using the Suggest Software feature available in SecTeer VulnDetect, you can quickly request SecTeer to start monitoring the missing software. Requests from our customers are highly appreciated and will be promptly addressed.

Yes, you can request this through your account or by sending the request to support@secteer.com. We will then assess your request and if applicable, add the package and support the software in the future.

Yes. All the communication between the SecTeer VulnDetect Agent or the SecTeer VulnDetect Graphical User Interface and SecTeer is made through port 443, and by using SSL protocol with 256-bit encryption.

No. Due to its lightweight design, SecTeer VulnDetect is able to run in the most common Windows systems. For more detailed information, please refer to the system requirements for running the SecTeer VulnDetect Centralised Dashboard.

Yes, all our packages rely on PowerShell 5.1, the default version on Windows 10 and Windows 11 and modern Windows Server releases. Our PowerShell scripts are digitally signed.

The package scripts download the installers via https / port 443 from our CDN / proxy hosts stream.vulndetect.com.
This allows you to proxy and locally cache the updates, depending on the capabilities of your proxy.
The package scripts always attempts a Windows Background Intelligent Transfer Service (BITS) first. If BITS is enabled and configured correctly, it will cache the installers on the local network. Please refer to the appropriate Windows documentation for more details.

The VulnDetect TSPM packages are all PowerShell scripts.
These scripts are all signed, and we recommend whitelisting/allowing all scripts that are signed by SecTeer VulnDetect.
SecTeer recommend using the built-in AllSigned security policy, as this improves your general security posture, if it is compatible with your other applications and management tools that use PowerShell.
If your 3rd party security solution doesn’t support whitelisting based on digitally signatures, you may be able to whitelist certain locations:
C:\Programs Files (x86)\SecTeer VulnDetect\
C:\ProgramData\SecTeer VulnDetect\
C:\Users\<username>\AppData\Local\SecTeer VulnDetect\
The user path is based on Env:\LOCALAPPDATA, so it may differ from system to system though this is rare.
Note that scripts running in Program Files and ProgramData all run as SYSTEM.
Scripts running in the user’s folder always run with the users’ privileges, as reported by the operating system.
Most tasks are launched via the Windows Task Scheduler; however, some may be initiated directly via the agent.

The most likely explanation is that an antivirus program uploaded the secteerSetup.msi file and a researcher at that antivirus company installed the program. You can safely delete the agent in the interface. It’s important to note that the MSI file you have received is keyed to your account, so anyone who receives it can run it, and the resulting agent will also be keyed to your account. There is no security issue here because the agent doesn’t receive any significant information from the server.

The packages from VulnDetect are compiled and tested in Denmark, which is part of the EU.

We create a package which downloads the installer directly from the vendor (or in a few cases our archive). All downloads are checked using a sha256 checksum which we embed in the package.

We always verify the digital signature.

To the extent possible, the sha256 sum which we embed in the package is calculated based on installers downloaded via https from official sources, and we verify the Authenticode signature of the installer when available. In rare cases where one or both https and Authenticode isn’t possible, the file will be vetted using other mechanisms such as VirusTotal, GPG, or other hash/checksum sources.

Our agent downloads the package (PowerShell script) from our server via HTTPS and verifies that the retrieval was conducted through our server.

When the agent is successfully installed, a unique auth-token is added to the registry. This auth-token is associated with the supplied email and used to identify the agent when it communicates with the SecTeer VulnDetect backend servers. The auth-token will remain until the agent is uninstalled. Upgrading will always preserve the existing auth-token. In order to get a new auth-token, and associate the agent with a different account, the agent must be manually uninstalled, and then the admin can deploy the MSI, which will create a new auth-token that is associated with the correct account.

Yes, that is possible by going to Groups -> Edit Selected Group -> Custom Inspect & Update Schedule

The most common reason is that the host is offline or hibernates.
Other times, the package may be waiting for the Windows Installer database, it will wait for up to two hours, before abandoning the update. The update will not be retried until the next regular or manual inspection.
In rare cases an installer may hang, this can be due to local configuration issues, conflicts or unexpected dialogues (which usually will be invisible to the user).
The package will time out after 59 minutes.
The update will not be retried until the next regular or manual inspection.
Also, only one package task can run, despite the Applying state in Package Activities, the other package tasks will wait for the first package to complete or exit due to one of the above mentioned timeouts.
The order in Package Activity is not indicative of the order in which multiple packages are attempted.

Note: In rare cases the Windows Installer database is locked for a very long time, this may be due to other installers running including Windows Updates. In some cases a restart of the host may be required to free the Windows Installer database again.

In some cases, due to the update requiring a restart, we specify that the app requires an “app restart” under “Patching activity.”

We are also looking into ways to alert the user to restart the system or force restart at a certain point. Please contact your account manager to discuss future feature implementations.

We strive to provide accurate and useful information about the current state of each product, e.g., if it is “OK” or “Insecure” and what type of update we are dealing with, i.e., “Plain/Bugfix Update” or “Security Update”. Unfortunately, not all vendors provide this information, although other parties may have published security information at some point in the past.

Therefore “Untracked” doesn’t mean that we don’t detect the application. It means based on our in-house research, the security and release information from the vendor is not considered reliable.

In general, all beta/alpha/insiders/canary/nightly and other pre-release channels for software is considered *Untracked* as most vendors don’t provide information for this kind of release.

We support a particular setting, ensuring that updates are distributed over a specific time interval. The default is a 7.5-hour window, during which all agents will conduct scheduled inspections also will run the “approved” update tasks. This window can be slightly expanded but ensures the evenest distribution should be aligned with the most common work hours.

Actual inspections are randomly distributed over an interval of up to 10 hours, starting at the selected time.
Applicable updates will run shortly after an inspection is completed.

Yes, VulnDetect uses BITS (Background Intelligent Transfer Service) from Microsoft and allows system administrators to download packages/updates with little impact on the network traffic and bandwidth.

VulnDetect can support an unlimited number of hosts through the multi-site and single-site structure.

VulnDetect offers the option ‘Automatically group new hosts based on their Active Directory groups.’ which will mirror the pre-configured groups present on customers AD.
The option is only available to System Administrators. To group existing hosts you will have to make a request to support@secteer.com

The difference between Hidden and Dormant hosts, is that Hidden is based on a admin action, whereas Dormant is 100% automated. This also means that a Dormant host that becomes active, will be revived automatically, whereas a Hidden host requires an admin action.

All hosts will stop counting license wise after 45 days, if they are inactive.

When an agent is installed on a host, it generates a unique token and saves it in the Windows Registry on that host.

That unique token identifies that host to SecTeer VulnDetect.

When the agent is upgraded, it preserves the unique token and thus preserves its identity.

When an agent is uninstalled, the unique token is deleted from the Windows Registry and cannot be recovered.

If the agent is installed again on that host, it generates a new unique token and a new identity.

This shows up on the Hosts page as multiple instances of the same host.

All results are counted for all the duplicate hosts while they are present on the Hosts page.

Yes.
For this to work, the MSI needs to be run with the following options:
msiexec.exe /quiet /i secteerSetup.msi WRAPPED_ARGUMENTS=”/options=group=groupname”
groupname must be replaced with the group’s full name in VulnDetect.

If the group name has spaces, then the options we recommend are the following:
msiexec.exe /quiet /i secteerSetup.msi WRAPPED_ARGUMENTS=”/options=group=””group name with spaces”””

Those are regular double quotes, first 1, then 2, and then 3 at the end.
Also, note that the agent will remain ungrouped if the named group does not exist.

Yes, you can request this through your account or send the request to support@secteer.com. We assess your request and, if applicable, add the package and support the software in the future.

We only download installers from official sources and verify the Authenticode Signature.
Software like Mozilla Firefox is verified based on the official GPG signed SHA256SUM lists.
However, for a few applications, like 7-Zip which aren‘t signed, we rely on services like VirusTotal and Jotti.org.
We also deploy such apps to a few test systems which run up-to-date anti-malware / endpoint protection software, before approving it for customers.
This is also the primary reason why there is certain proprietary software we don‘t support, when the official installers aren‘t publicly available from official sources.
Before running any installer that is downloaded via our proxy / CDN, the SHA256SUM of the file is checked against the entry we have stored in our database, both to prevent Man-in-the-Middle attacks as well as avoiding to execute a corrupted installer due to network issues.

Yes, in most cases this will not be an issue. However, you should ensure that the applicability rules for packages applied via other means accept newer versions of the applications, so the applications aren’t downgraded by your deployment tool.

Customer data is stored in SQL databases. We operate with an individual database per customer. This guarantees against data leaks and allows us to easily scale our setup, by e.g. distributing individual customers to different hardware instances. It also allows us to easily purge customer data, if or when a contract is cancelled.

1) Set a string value in the registry, under HKLM\Software\WOW6432Node\SecTeer\Agent
2) The value name is overrideGroup, the value itself is the name of the group that the agent should be in
3) The agent service must be restarted for the agent to read the value and submit it to the backend
4) The backend looks up the group by name, case-insensitive, and if found, it moves the agent to that group
If no group is found with the given name, then the setting has no effect
If multiple groups are found that match the name, then one will be chosen. Which group is chosen is arbitrary, but consistent (it is the first one, ordered by their uuid)
5) The overrideGroup setting persists in the registry, so if the agent is later manually moved to a different group, then it will revert back to the overrideGroup the next time the agent service starts, unless the registry setting is cleared. This will be altered in a future agent release, so that the agent itself will clear the setting, after sending it to the backend.

Do let us know if you have further questions or experience issues. Bare in mind, that this is a new feature, currently only used by one other customer.

Currently, jobs can’t be completely deleted, only stopped. We are considering ways to allow deleting (or automatically hiding old stopped) jobs.

1) Open Edge browser

2) Open the website that you want a shortcut to

3) Open the Edge main menu (three dots on far top right)

4) Hover on the “Apps” menu option

5) Click on the “Install this site as a web app” option > click “Install”

6) Tick the boxes for creating a Desktop shortcut and pinning the app to the Taskbar and/or Start Menu, then click “Allow”

That’s it! Instead of creating a shortcut to a website URL on Edge, you have installed that page as a Web App (PWA), and added a shortcut to it.

The Windows Updates page only shows the updates that are available and not yet applied.
The Windows Update Approvals page show some of the recently applied updates, but those covered in cumulative updates or other major updates of the OS seems to be hidden by the WU API, because these larger updates already include the smaller more specific updates. The data shown is based on the Windows Update API and should closely reflect what you see in the local UI of the Host.
So the Windows Updates page shows the current status of windows updates across the environment, while the Windows Update Approvals gives the user options to apply or block updates.

The Windows Update feature pulls available updates via the currently configured Windows Update service, this means that it will query your WSUS if this is configured.
If WSUS isn‘t updated with the most recent updates, these will not be visible in VulnDetect. In short, it will use the configured Windows Update on the host, if that is WSUS, then we query WSUS, if not, then it will typically be the public one.

Drivers are supported via Windows Update, to the extent that the drivers are available via the Windows Update (server) endpoint that is configured on the host.

Windows Update Approvals cannot be automated because Windows updates are not versioned, so a Windows Update Approval is never Out-of-Date.
Setting a Windows Update Approval to approve updates is sufficient to make the system apply that Windows Update to all applicable hosts.

In essence, all updates in VulnDetect are run within minutes of a scheduled or manual inspection. This, is also true for Windows Updates. Only updates that has been rescheduled to run during startup or login are exempt from this logic, i.e. this is irrelevant for Windows Updates.

The use of Windows Update approvals within VulnDetect does not prevent Windows Updates to be installed by other means, e.g. the built-in Windows Update Agent in Windows or other tools.

To fully manage Windows Updates with SecTeer VulnDetect, an Active Directory Group Policy can be configured to disable automatic application of Windows updates by the Microsoft Windows Update service.

There is an option to approve ALL future Windows Updates by default by editing a group setting and turning on the “Default Status for new Windows Update Approvals”. Note that this will not apply to existing WU Approvals, you will have to manually approve them.

You can send your question directly to support@secteer.com, and a solution specialist will be assigned to you and assist with your query.