Is a detection on a remote access tool a false positive?

Often, but not automatically. The behaviour genuinely resembles remote access malware. Verify the signature, source and hash before deciding, because attackers do use legitimate tools.

Should I turn off antivirus to install the agent?

No. Create a precise, documented exclusion for the verified binary instead. Disabling protection during installation is how machines end up unprotected permanently.

How narrow should the exclusion be?

As narrow as resolves the block: a signed publisher or an exact executable path, applied through central policy. Never a whole folder or a disabled protection module.

Why does it only get blocked when I take control?

Behavioural protection triggers on specific actions such as input injection or screen capture, so the block appears when you use the feature rather than at install time.

Troubleshooting · 6 min read

When antivirus or endpoint protection blocks remote access

Written for: IT and security staff whose remote access agent is being quarantined, blocked or flagged by endpoint protection.

In short

Remote access agents look, to a scanner, a great deal like the tooling an attacker would install: they run as a service, capture the screen, accept input and connect outbound. That similarity produces false positives and behavioural blocks. The right response is neither to disable protection nor to ignore the block, but to verify the binary, allow-list it precisely, and document why.

Key takeaways

Remote access tooling is genuinely dual-use, so detections are expected rather than surprising.
Verify the binary's signature and origin before allow-listing anything.
Allow-list by signed publisher and precise path, never by disabling a scanner or excluding a whole directory.
Behavioural blocks often appear only under specific actions — screen capture, input injection, elevation.
Record every exclusion with a reason and a review date, or it becomes an unexplained hole nobody will dare remove.

Why legitimate tools get flagged

Endpoint protection increasingly judges behaviour rather than signatures, and the behaviour of a remote support agent overlaps almost perfectly with the remote access trojans it exists to stop. It installs a persistent service, captures the display, injects keyboard and mouse input, elevates privileges and maintains an outbound connection to a server on the internet.

Attackers also abuse genuine remote support tools directly, which is why some vendors flag well-known products by name. A detection is therefore not evidence the software is malicious, nor evidence it is safe. It is a prompt to verify.

Verify before you allow

Check the digital signature on the binary and confirm the publisher is who you expect. Confirm the file arrived from the vendor's own download or your own deployment package, not from a link in a ticket or an email. Compare the hash with the vendor's published value where one is offered.

This matters more than it sounds. Social-engineering attacks that persuade someone to install a real remote support tool are common, and the detection you are about to suppress may be the control that would have stopped one.

Signature valid and publisher as expected
File obtained from the vendor or your own package repository
Hash matches the vendor's published value
Installation was initiated by your team, not requested by a caller

Allow-list precisely

Once verified, create the narrowest exclusion that resolves the block: the specific signed publisher, or the exact executable path, for the specific behaviour being blocked. Excluding an entire folder, or turning off a protection module, converts a targeted allowance into a general weakness that any file dropped in that location inherits.

Push the exclusion through central policy rather than configuring machines individually, so it is consistent, visible and reversible in one place.

Document it

Every exclusion should carry the product it covers, the reason, who approved it and when it should be reviewed. Undocumented exclusions accumulate, and because nobody can remember why they exist, nobody removes them — including after the product they covered has been decommissioned.

A short quarterly review of the exclusion list catches those, and gives you a clean answer when an auditor asks why your endpoint protection has holes in it.

Common mistakes

Disabling endpoint protection to complete an installation and forgetting to re-enable it.
Excluding a whole directory such as Program Files, which allows anything later dropped there.
Allow-listing a tool because a caller asked you to — the classic remote-access social engineering route.
Creating exclusions locally on individual machines, so nobody can enumerate them later.

Frequently asked questions

Is a detection on a remote access tool a false positive?: Often, but not automatically. The behaviour genuinely resembles remote access malware. Verify the signature, source and hash before deciding, because attackers do use legitimate tools.
Should I turn off antivirus to install the agent?: No. Create a precise, documented exclusion for the verified binary instead. Disabling protection during installation is how machines end up unprotected permanently.
How narrow should the exclusion be?: As narrow as resolves the block: a signed publisher or an exact executable path, applied through central policy. Never a whole folder or a disabled protection module.
Why does it only get blocked when I take control?: Behavioural protection triggers on specific actions such as input injection or screen capture, so the block appears when you use the feature rather than at install time.

How this works in 247connect

247connect ships signed installers so endpoint protection can be allow-listed by publisher rather than by path, which keeps the exclusion narrow and survives version updates.

Start a 14-day free trial See the feature list