Troubleshooting FAQ

• Windows - It attempts to use the Admin SMB share to send a small executable called the dissolvable agent that it then runs on the remote machine to fetch the details.

• Active Directory - If Active Directory Credentials are provided to the Probe Agent under Discovery Settings, it uses SMB communication to fetch information from remote assets.

• Linux - requires the latest installation of NMAP; uses SSH credentials and Linux commands to determine what is running

• Network Devices - Uses SNMP to discover the sysObjectID, look up the version of the device, and then query the vulnerabilities for the version. It also connects to OEM APIs to get the vulnerability details.

• You can discover multiple subnets using a single Probe Agent by setting up the address type(s).

  • CIDR > Example: 192.168.1.0/24

  • IP Range > Example: 192.168.1.0-192.168.1.100

  • Static IP > Example: 192.168.1.1

• Network scanning involves detecting all active hosts on a network and mapping them to their IP addresses.

• Port scanning refers to the process of sending packets to specific ports on a host and analyzing the responses to learn details about its running services or locate potential vulnerabilities.

Host discovery, the process of determining what systems on a network are up and listening, is often the first step in a hostile network scanning action. Two protocols are most commonly used for host discovery: Address Resolution Protocol (ARP) scans and several types of Internet Control Message Protocol (ICMP) scans.

Since individual ARP requests are used to map IP addresses to MAC addresses on a local subnet, ARP requests can be sent out to many IP addresses on a Local Area Network (LAN) to determine which hosts are up based on the ones that respond with an ARP reply.

For network scanning outside of a local subnet, several types of ICMP packets can be used instead, including echo, timestamp, and address mask requests. Echo (or ping) requests are used to detect if another host can be reached, while timestamp messages determine the latency between two hosts. Address mask requests are intended to discover the subnet mask in use on the network.

Host discovery for each ICMP message type depends on receiving a corresponding reply from available hosts. If no response is received, it means either that there is no host listening at that address, that the request packet was blocked by a firewall or packet filter, or that the message type isn't supported by the destination device. ICMP echo requests that originate outside an internal network are commonly blocked by firewalls, but timestamp and address mask requests are less likely to be blocked.

Once available hosts on a network have been found via networking scanning; port scanning can be used to discover the services in use on specific ports. In general, port scanning attempts to classify ports into one of three designations:

• Open: the destination responds with a packet indicating it is listening on that port, which also indicates that whatever service was used for the scan (commonly TCP or UDP) is in use as well

• Closed: the destination received the request packet but responded with a reply indicating that there is no service listening at the port

• Filtered: the port might be open, but the packet has been filtered out by a firewall and dropped, so no reply is received

As previously mentioned, TCP and UDP are frequently the protocols used in port scanning. There are several methods of performing TCP scans:

SYN scans, the most common form of TCP scanning, involve establishing a half-open connection to the target port by sending a SYN packet and evaluating the response. The host replies by sending a SYN/ACK packet if the port is open or a RST response if the port is closed. It is also possible for a closed port to reply with an ICMP port unreachable message instead of a RST packet, though this is less common. A lack of any reply indicates that the port is filtered.

A higher level method of TCP scanning is the TCP connect scan, in which the scanner tries to connect to a port via TCP using the connect system call and the full TCP handshake process. This method is utilized less often than SYN scanning, since it requires more overhead in terms of packets and time and is more easily detectable.

NULL, FIN, and Xmas scans are three scan types that involve manipulating TCP header flags. Each of them results in a RST (or ICMP port unreachable) packet from a closed port and no response from an open or filtered port, and they require that the SYN, RST, and ACK bits are not set. NULL scans send packets with no flags set in their headers, while FIN scans have only the FIN bit set.

• CPU: 4-core

• DISK: 50GB SSD

• RAM: 4GB for first 1000 assets and 1GB for every 500 assets added

• Network access to any subnets to be scanned based on mapped discovery settings

• The latest version of NPCAP (may require uninstalling the previous/older version of NPCAP to convert from LWA to Probe)

• Linux requires the latest NMAP installed

• MacOS requires the latest NMAP installed

• Probe Agent will require AD credentials to scan the Active Directory environment(s).

  • See: Active Directory Least PrivilegesPreviewfor setting up permissions

  • See: V4 IntegrationsarchivedPreviewfor supported integrations (CSP and Non-CSP)

  • See: https://app.storylane.io/share/p0h16zmx8o1r for how to add AD creds

• Probe Agent can access workgroup machines using standard or local credentials mapped from the Discovery settings to the Probe (nondomain).

  • See: https://app.storylane.io/share/4rmxid8ljyoc

You can validate the credentials from the probe agent machine; check out the guide:

Troubleshooting FAQ | Windows Asset Credential Scan Issues (SMB)Preview

At this time, ConnectSecure probes are unable to scan their own external ports.

This limitation is due to how network-level scans are performed—probes cannot evaluate their own exposure from an external perspective.

Steps to Run Nmap Commands:

Open PowerShell as an administrator on the Probe agent machine.

Navigate to the Nmap folder by running:

cd "C:\Program Files (x86)\CyberCNSAgent\nmap\"

Execute the following Nmap commands:

nmap -n -Pn -T4 --min-parallelism 100 --max-parallelism 255 --top-ports 100 <IP>

Additionally, please verify if the asset is reachable by running the following command in PowerShell (run as administrator):

Run the following command:

ping <IP>.             (Replace ip with the actual ip)

The location of cybercnsagent.exe depends on how the asset was scanned:
• If scanned using a probe agent, the file may appear under the Windows directory. This is because required templates are temporarily copied to the Admin Share path during the scan.
• If deployed via a lightweight agent, the file is typically installed under Program Files (x86).
Note:
If the asset was previously scanned with a probe agent, you may still see remnants of these templates in the Windows directory—even after installing the lightweight agent. This is expected and does not indicate a malfunction.

The default installation path:

Windows: C:\Program Files (x86)\CyberCNSAgent

MacOS/Linux: /opt/CyberCNSAgent

The default path for the logs:

Windows: C:\Program Files (x86)\CyberCNSAgent\logs

MacOS/Linux: /opt/CyberCNSAgent/logs

The default log files:

• cybercns.log (main)

• cybercns_monitor.log

• cyberpatch.log (patching)

• Select the Online Lightweight or Probe agent

• Select Fetch Logs for that agent and wait for few minutes for that log to be fetched

• Select Download logs and it will download the agent logs.

Open

The agent is configured to restart at regular intervals (every 3 hours), and the cybercnsmonitor agent is actively responsible for monitoring the status of all agents.

When troubleshooting issues with Google Workspace Assessments—such as scan failures, missing data, or unexpected behavior—local log files can be found here

For Windows:
%LOCALAPPDATA%\Google\Google Workspace Assessments\logs

For macOS:
~/Library/Application Support/Google Workspace Assessments/logs

Step-1:-
Stop the agent service

Open PowerShell as an administrator

net stop cybercnsagent

net stop cybercnsagentmonitor

Step-2:-

uninstall the npcap driver from the installed programs.

Install the npcap oem latest version from our agent folder, "C:\Program Files (x86)\CyberCNSAgent\nmap"

Step-3:-

Start the agent service

net start cybercnsagent

net start cybercnsagentmonitor

If fingerprint or discovery data is missing for certain assets, it may be due to limited scan visibility caused by the selected network interface.
To improve detection accuracy, we recommend the following:
• Go to Probe Discovery settings.
• Set the Network Interface to “None”.
• Run a full scan.
This configuration allows the probe to perform deeper network analysis, resulting in more complete Nmap details and device fingerprints being populated in the portal.

If the agent is installed but still not appearing in the ConnectSecure Portal, please follow the steps below to verify and restart the service:

Run the following commands:

cd /opt/CyberCNSAgent

sudo ./cybercnsagent_darwin -w

This command will force the agent to re-register and communicate with the portal.

After running it, please wait for 10–15 minutes and check if the asset appears.

If not, share the latest logs from the /opt/CyberCNSAgent/logs/ folder for further analysis to the support team.

To resolve this, please exclude the following printer-related ports from your scanner’s port exclusion policy:
Recommended Ports to Exclude: 9100, 9101–9103, 515, 631, 9021–9022, 18080

To exclude the required ports, please follow these steps:

1. Navigate to Company Settings at the company level.

2. Select the Ports Policy tab.

3. Under the Excluded Ports section, please enter the following ports:
   9100, 9101–9103, 515, 631, 9021–9022, 18080

4. Once entered, click the Save button to apply the changes.

Refer the below attached screenshot for your reference.

Open

If the CyberCNS agent service is active but the device is not appearing in the portal, follow these steps:

Open PowerShell as an Administrator on the agent machine. Step1: Navigate to the following path. cd C:\Program Files (x86)\CyberCNSAgent\

Step2: Run the command.

.\cybercnsagent.exe -w

Please follow these steps to verify and re-register the agent:

1. Open a terminal on the Linux agent machine with root privileges.

2. Navigate to the CyberCNS agent directory. The default install path is: cd /opt/CyberCNSAgent/ 

3. Run the agent with the registration flag.

This forces the agent to reattempt registration with the central server: sudo ./cybercnsagent -w 

Please share any errors also if you are still facing issues share the Company, Agent and logs ​

MacOS/Linux: /opt/CyberCNSAgent/logs with support@connectsecure.com

Directory missing → Re-install

• If the installation folder doesn’t exist, the software probably isn’t installed properly. The fix is to reinstall it.

EXE missing → Fresh download

• If the main program file (.exe) is not found, re-download it.

EXE <100 KB → Fresh download

• If the .exe file exists but is smaller than 100 KB, it’s likely corrupted. Re-download it.

EXE exists → Version check

• If the .exe is present, check which version is installed.

Outdated version → Fresh download

• If the version is old, download the latest one.

Valid → Start services

• If the .exe is present, the size is fine, and the version is up-to-date, then just start the related services.

Use the three dot action menu in the Agent view > Reset Agent Configuration > Reset Agent > Allow 5-10 minutes and check back in the All Asset view to confirm the Agent has appeared.

Open

Open

If you are still facing issues reach out to support@connectsecure.com

Some antivirus (AV) or cloud-based security tools may automatically install agents or executables as part of their sandboxing or endpoint protection routines. This can result in an agent install being logged under a user’s name—even if they didn’t manually trigger it.

For any partners who are using the Continuum RMM platform, please be aware of a character limitation in their product for the ‘value' field where we would store the User Secret.

Open

To work around this limitation, simply add the User Secret value to the script itself and do not use the Value field.

Ref: https://cybercns.freshdesk.com/a/tickets/58075

To generate a new token and reset the user secret:

1. Sign in using the email address that is experiencing the error. 

2. Navigate to the company you have access to, then go to:
   Overview → Agents → Lightweight Agents and click on Download Agents.
   Please wait a few seconds on this page.

3. As soon as you open this page, a token will be generated automatically.

4. Once that’s done, go to Settings → Users, select the affected user, and choose Reset User Secret.

Please follow these steps to whitelist the directory:

Step 1: Log in to Bitdefender GravityZone
Go to the Bitdefender GravityZone Control Center and log in with your credentials.
Step 2: Navigate to the Policies Section
On the left-hand menu, click on “Policies.”
Select the policy that applies to the endpoints where the directory needs to be whitelisted.
Step 3: Add Directory Exclusion
In the policy settings, click on “Antivirus.”
Scroll down to the “Exclusions” section.
Click on “Add” to create a new exclusion.
Step 4: Configure the Directory Exclusion
Exclusion Type: Choose “Folder” as the exclusion type.
Path: Enter the full path to the directory you want to exclude (e.g., 'C:\Program Files (x86)\CyberCNSAgent\').
Description: Optionally, provide a description for the exclusion for easier management.
Step 5: Set the Exclusion Scope
Define the scope of the exclusion, such as whether it applies to on-access scanning, on-demand scanning, or both.
Click “Save” to apply the exclusion.
Step 6: Verify the Exclusion
After applying the changes, test on an endpoint to ensure that the directory is no longer being scanned or flagged by Bitdefender.
Reference
You can refer to the detailed guide on adding exclusions in Bitdefender GravityZone by visiting this link:
https://www.bitdefender.com/consumer/support/answer/13427/

REF: https://cybercns.freshdesk.com/a/tickets/49777

If any asset(s) fail due to invalid credentials, we display the message ‘Credentials Not Available For Scan’ at the asset details screen as shown below:

Open

We have included the following platform checks here:

• VMWare

• Network Device

• Linux

• Windows

• Darwin

• MAC

• Linux-based OS

• Ubuntu

• NetBSD

• FreeBSD

• Linux Kernel

• Debian

• Debian Linux

• RHEL

• Red Hat

• CentOS

• Fedora

Add Credentials

Tap on the key icon in the asset details screen for any probe-discovered asset to add credentials directly against the asset instead of having credentials mapped to the probe itself.

Open

1. Go to the ConnectSecure portal.

2. As shown in the top right corner of the first image, click on the icon and select 'Profile.' This will direct you to your Zitadel account.

3. Click on the user icon.

4. In the 'Action' menu, select 'Unlock User.'

Open

Open

Open

Ref: https://cybercns.freshdesk.com/a/tickets/48850

When scanning Windows 7 assets, the probe agent can retrieve system-related information, such as the system name, platform, and other pertinent details, through network scanning, port scanning, and network assessment. However, the probe agent can only detect Windows 7 devices via network scans and is unable to perform authenticated scans by applying credentials to these devices. Windows 8 is supported for authenticated scanning. For Windows 7, the probe agent will list any detected network vulnerabilities, along with network-derived information and the asset's fingerprint, which will be displayed in the asset view.

Ref: https://cybercns.freshdesk.com/a/tickets/56608

We have removed Microsoft Edge and Microsoft Teams from the patching process. This decision was made because the upgrade has proven to be unreliable with the offline patch installers, which has caused issues with the update. Once the team has this sorted out, we will make these applications available again.

If an asset does not have enough memory an error may appear in logs:

Open

This indicates that certain files required by the update were in use at the time of installation. This can happen if system services, background applications, or other processes are locking the files needed for patching.

Check if there are any services or applications running on the device that might be using these files and preventing the update from installing. Additionally, please confirm if there is any firewall rule, security product, or third-party application—such as an antivirus or threat locker—that could be blocking the update process.

This error generally indicates that the installation failed due to file access restrictions or temporary system conditions while executing the update file. as our agent utilizes WSUS to execute patches with the required privileges. We recommend verifying that there are no file locks or pending system reboots that might interfere with the update installation.

1. Add the osquery repository:

sudo yum-config-manager --add-repo https://pkg.osquery.io/rpm/osquery-s3-rpm.repo

2. Install osquery:

sudo dnf install osquery -y

3. Run osquery query:

osqueryi "SELECT * FROM programs WHERE name LIKE '%App%';"

When uninstalling Python, the uninstaller may not always remove the Python Launcher executable completely from the system.

This could be the reason the agent is still detecting its presence even after reinstallation.

We recommend manually checking and deleting the Python Launcher (python.ex or py.exe) from the following locations, if they still exist:

• C:\Windows\

• C:\Windows\System32\

• Or any custom installation path used earlier.

Once the launcher file is removed, please reinitiate a scan on the affected asset to confirm the alert is cleared.

Our scanner has detected that mDNS (Multicast DNS) is currently running on the asset. While mDNS helps devices on the local network discover each other by broadcasting information, it also enables communication across the network without authentication, which can introduce potential security risks.
Because of this behavior, the ConnectSecure vulnerability scanner is designed to flag mDNS as a concern. This ensures partners are aware of any unauthenticated broadcast protocols that may increase exposure.

Vulnerabilities shown in the red banner are determined through a combination of factors rather than a single criterion. Specifically, our system highlights vulnerabilities that fall into one or more of the following categories:
• CISA KEV-listed vulnerabilities
• Vulnerabilities assessed as critical severity (CVSS ≥ 9.0)
• Vulnerabilities confirmed to be actively exploited in the wild, based on intelligence feeds from multiple trusted sources
• Critical vulnerabilities published by key vendors such as Microsoft, Google, Zoom, and Mozilla, where exploitation could have a significant impact

1. Make sure a recent scan has been completed

2. Use the OSQUERY to determine application details

How To: Use OSQuery to Validate Installed SoftwarePreview

This script is intended to help partners remove applications across multiple endpoints efficiently using your RMM.

Below is an example where you will need to enter the target application into the script provided to begin the uninstall process.

Open

Click Below

LLMNR registry value changes are detected only during a full scan cycle, which typically runs every 6 hours. These checks are not performed during the more frequent self-scans, as registry-related validations are designed to occur during full scans to ensure accuracy and reduce unnecessary system load.

Assets are flagged with the OS-OUT-OF-SUPPORT vulnerability when the operating system version has reached end-of-life according to Microsoft’s official lifecycle timelines. Once an OS version is no longer receiving security updates, it poses a long-term risk and is marked accordingly.
Why Are There Two OS-Related Findings?

Some assets may show both a Software Patch finding and an OS-OUT-OF-SUPPORT finding. This is intentional. Each serves a distinct purpose:
• The Software Patch finding indicates that the OS is still supported but has known vulnerabilities that require patching.
• The OS-OUT-OF-SUPPORT finding highlights that the OS version is no longer supported and will not receive future security updates.

Both findings are necessary one addresses active threats, while the other ensures visibility into lifecycle and compliance risks.
For more information, we recommend reviewing Microsoft’s lifecycle documentation for Windows 10 and Windows 11.

Windows 10 Lifecycle: https://learn.microsoft.com/en-us/lifecycle/products/windows-10-home-and-pro
Windows 11 Lifecycle: https://learn.microsoft.com/en-us/lifecycle/products/windows-11-home-and-pro

The vulnerabilities being flagged are related to an older version of a driver installed on the machine, not the software itself.

Outdated drivers can sometimes have known security vulnerabilities. To resolve the issue, we recommend updating the driver to the latest version available from the manufacturer.

You can search the installed drivers by navigating to the All Assets > Select the affected Asset > System information > Installed Drivers and search for Dell peripheral.

Open

We use the PowerShell command below to find the Teams app on devices and check if any leftover cache data from the old version still exists.
You can verify by executing this PowerShell command below

The vulnerability you’re seeing is caused by Microsoft Teams roaming profiles. Even after updating to the latest version, some older Teams files or paths can remain cached in the user’s roaming directory, which triggers the flag.

If you don’t want to see it, please disable the roaming profiles under Global Settings > Roaming Applications, and disable the Roaming Application Status for the specific companies.

Zoom application may be detected in the software inventory due to its presence in a user’s roaming profile.

You have two options:

1. Manually clear the files from that path.

2. Disable the roaming application under Global Settings.
   
   

Disabling the roaming application will ensure the system ignores any files in the cache path or user profile path, preventing it from considering leftover files from previous installations.

Microsoft lifecycle documentation here, which lists end-of-life details and supports informed decision-making regarding such components:

https://learn.microsoft.com/en-us/lifecycle/products/

MySQL Connector/J is no longer distributed as an MSI or EXE installer. Starting with version 9.x, it is provided only as a standalone JAR file intended for direct integration into Java projects, rather than system-wide installation.
Earlier versions of the MySQL Installer bundled Connector/J 8.0, which is why it may still appear on some machines and trigger vulnerability alerts.

Resolution Steps:
• Uninstall Connector/J 8.0 if it was installed via the legacy MySQL Installer and no applications depend on it.
• Use the latest Connector/J JAR (such as version 9.4) in your Java projects as needed.
• Since MySQL no longer provides an MSI or EXE for Connector/J 9.x, this JAR-based approach is the standard and secure method going forward.
• If uninstalling is not feasible, you may choose to suppress the alert after confirming the legacy version is not actively used.