- A researcher reports two ScreenConnect clients on one lab host. The researcher says both carried valid ConnectWise signatures, and one was used to install the other.
- According to the researcher, the signature did not separate the two. Counting ScreenConnect services and checking which relay each calls did.
- Leaders should ask which remote tools are approved, whether unapproved ones raise alerts, and whether ScreenConnect event logs are kept.
A signature tells you who built the tool, not who is using it
Security teams lean on digital signatures. A valid one says a known vendor produced the file. It says little about who is at the other end of the connection. One researcher's case shows how wide that gap can be.
The account is a Reddit post by /u/securityinbits, published October 31, 2026, plus the author's replies in the thread. It describes a single lab host, and the author links a video walkthrough. The post does not say whether the activity was a real attack or a lab simulation. It is one self-reported case. WebPulse has not verified it.
How a signed tool can serve two owners
This section is general background, not from the post. A code-signing signature shows that a file was signed with a vendor's certificate and was not changed afterwards. It covers the file, not the settings.
A ScreenConnect client is configured with the address of the server it calls back to. That server is called a relay. So the same signed program can serve different owners, each pointing at a different relay.
What the researcher found
The researcher reports two ScreenConnect clients on the same host. ScreenConnect is a remote-access tool. According to the researcher, the first client was what put the second on the machine. The second then called a server the operator controlled. Each client ran as its own service.
The researcher says both carried valid ConnectWise signatures. On that evidence, a valid signature alone did not distinguish the two.
What did separate them was a simple check. Count the ScreenConnect services on the host, then inspect which relay each one calls. Multiple instances, the researcher says, need investigation and context.
A caution came later, in a reply in the comment thread rather than in the original post. The researcher wrote that removing one client leaves the other running.
The trail the tool leaves behind
The details in this section come from the researcher's follow-up comments, not the main post. The researcher suggests collecting Windows Application logs from the ScreenConnect provider. Event IDs 100 and 101 record sessions connecting and disconnecting, with operator display names. Event ID 201 records file transfers. In this case it logged the second installer being transferred with the action "Run".
The researcher also saw the process ScreenConnect.WindowsBackstageShell.exe running as SYSTEM. They say this gave the operator a hidden session. They also say the operator uploaded HideUL, Sordum's "Hide From Uninstall List" utility.
The researcher says the file hashes matched the stock utility. The hash values were not in the text WebPulse reviewed, so that claim rests on the researcher's word. By their account, the tool was ordinary. The malicious part was using it to hide ScreenConnect.
Other commenters described similar patterns. One wrote that threat actors had used "the exact same methodology" in recent weeks and advised looking for "HideUI" execution. The researcher spells the name "HideUL". This article reads the commenters' "HideUI" as the researcher's "HideUL", though the thread does not confirm they are the same utility.
Another commenter said they most often see a legitimately signed instance install one that is not signed. These are unverified comments, not research findings.
Where the AI fits
The post is partly about AI. The researcher used Claude Code to run queries on provenance and signers. Those queries covered archived Defender telemetry held in ADX, which uses the KQL query language, and in Elastic, which uses ES|QL. The researcher says every result was checked by hand.
The relay and operator-activity work was also done manually. That division of labour is the useful point. The model ran the provenance and signer queries across archived telemetry. A person decided what the results meant. The post does not say how much time this saved, so we make no claim about speed.
This article's reading of this one case is that automation can widen the search. The researcher does not make that claim. The judgement about whether a connection is legitimate still needs someone who knows the business. A tool can list every relay. Only your team knows which ones you approved.
Questions to put to your security team
First, which remote-access tools are approved in our environment? One commenter suggested keeping an allowlist of the tools you actually use. They also suggested alerting on any other remote client, signed or not.
Second, if we do not need ScreenConnect at all, can the endpoint detection product block it? Commenters in the thread made that point.
Third, do we collect the ScreenConnect event logs, and for how long? The researcher's own case relied on them to show the second installer being run. That suggests that without them, the record of what an operator did may not exist.
Fourth, who decides between cleaning a host and rebuilding it? The researcher offered a rule of thumb. If the evidence cannot show what an operator did inside the hidden session, they would preserve that evidence and then wipe and reinstall Windows.
A signature names the maker. The relay shows where the client calls home, and only you know whether that is yours.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Reddit (/u/securityinbits).
