A real remote-support installer can still be the wrong one

A meeting invitation or a support request is familiar business traffic. That familiarity is useful to an attacker asking someone to install software. A legitimate product name does not establish that the request came from your IT team.

What Microsoft reported

In research published September 29, Microsoft described July 2026 phishing campaigns that disguised an MSP360 remote-management installer as meeting, document, or software-update content. Successful deployments were used to install ScreenConnect as another remote-access channel. Microsoft reported abuse of legitimate administration software; it did not observe exploitation of ScreenConnect itself in this activity. Read the campaign analysis.

The joint CISA remote-access guide addresses the same broader control problem: useful administrative tools can be co-opted for unauthorized access. It offers detection and security recommendations for organizations that use them. Read the guide.

Verify the request through a known channel

A practical staff rule is simple: an unexpected request to install remote-control software needs a separate check. Contact IT or the provider using the number, ticket portal, or contact method you already know. Avoid using the phone number or reply path supplied by the unexpected message as the verification step.

This should be a normal part of support, rather than a test of whether someone can identify a convincing fake. Tell staff what an authorized request looks like and where to take a question.

Know what approved access looks like

My recommendation for the person managing the environment is to keep a small inventory of remote-support tools. Record the tool, the vendor or team allowed to use it, the endpoints it belongs on, and how access is approved and removed.

If two remote-control products appear on a device that should have one, that is a useful question to investigate. It is not, by itself, proof of a compromise. The inventory gives you a baseline for distinguishing expected support from unexplained access.

Make the response clear before it is needed

Staff should know who to contact if they have already installed an unexpected support tool. Ask them to report it promptly, preserve the message, and follow the organization's incident procedure. A fast report is more useful than embarrassment or a private attempt to fix everything.

The lesson for a small business is concrete: checking whether a file is signed is only one part of the decision. The request, the intended operator, and the access being granted all need to make sense.