Remote-access tool abuse: self-hosted ScreenConnect and similar clients

The pattern

ScreenConnect is a legitimate remote-support product, and similar products work the same way. A client installed on a computer calls a server and waits to be controlled from it.

In NSS-ZM-01 that client is the payload. Once installed, it calls the sender's server and waits. No exploit is needed, and security tools that trust remote-support software may let it run. A fake update page did the delivery.

A self-hosted instance

The sender did not borrow anyone's account. The download host, min[.]garincon[.]com, is a self-hosted remote-access portal with the greeting "Welcome to our online remote support and collaboration portal". The sender runs their own instance of the product.

That matters to a defender. There is no vendor account to report, and the client looks like any other copy of the product. What sets it apart is the server it calls.

Reading the client without running it

NSS fetched the installer once on 12 November 2026 at 13:11 UTC, took its hashes, read its settings and deleted it. A second fetch gave the same file. It was never run.

The settings say where the client goes:

• It connects to 524ff283-2094-4f98-b68d-f24f61c5f8fa[.]dotinicon[.]com on port 8041.
• Its client id is 230f9b38c3c088fe, installed as the service "ScreenConnect Client (230f9b38c3c088fe)".
• It is a Windows Installer package, author "ScreenConnect Software", 15,216,640 bytes.

What the client does after it connects comes from the product's known behaviour. NSS did not watch a session.

One server behind the names

Three records tie the download host and the connect-back host to one server, 45[.]87[.]61[.]155:

• The connect-back host resolves to it, and its relay port 8041 was open on 12 November.
• Asked by address on port 443, it serves the same portal page that the download host serves through a delivery network.
• It presents that network's origin certificate, issued on 13 October 2026, the day the portal's domain received its first public certificate.

So the portal is reached through the delivery network, and the relay is reached directly as a long random host name. Unlike the lure page's address, this server is in the paper's indicator list: the records tie it to this sender.

The operator's domains came first

The two operator domains were bought at the same registrar a month apart: dotinicon[.]com on 9 September and garincon[.]com on 12 October 2026. The lure was bought on 11 November. The connect-back domain is 63 days older than the lure.

The server and its names were set up once. The lure came later. A lure name recorded today can lead to infrastructure that has been in place for weeks, and that may outlive the lure.

Controls that catch it

In order of how much each one catches, from the paper:

1. Hunt endpoint records for the installer's SHA-256 and for a service named "ScreenConnect Client (230f9b38c3c088fe)". Both are in the paper.
2. Allow only the remote-support instances your organisation runs. A remote-support client that calls an instance you do not own is the finding, whatever the lure.
3. Alert on outbound connections to port 8041, and to the server address on any port.
4. Block the names and the installer address in the indicator list at DNS and at the web gateway.
5. Do not block the lure page's own address. It belongs to a shared hosting platform that serves unrelated sites.

The second control is the one that lasts. Names, hashes and addresses change with the next campaign. An allowlist of your own instances does not.

In ATT&CK terms

• T1219.002 Remote Access Tools: Remote Desktop Software: a remote-support client set to connect to the sender's relay.
• T1583.001 Acquire Infrastructure: Domains: three domains bought between September and November 2026.

For how NSS weighs records like these, see how NSS confirms infrastructure.