A signed support tool can still open the wrong door

SANS handler Xavier Mertens received an invoice-themed email that linked to a signed ScreenConnect client. The client itself was legitimate. Its configuration, however, would connect the machine to an attacker-controlled remote-support instance. Ullrich’s point is worth holding onto: this is abuse of a normal support workflow, not evidence of a flaw in ScreenConnect.

That distinction changes the investigation. A valid signature tells you who signed the software; it does not tell you who requested this particular session or why. If an unexpected support client appears after an email, I would want the originating message, download path, installed client configuration, remote-session history, and the user’s account of what they saw—before assuming a malware alert will tell the whole story.

Huntress found attacker-created custom GPTs posing as a product offering. The user started on a genuine ChatGPT page, then was sent to a Google Sites page that presented a fake verification step and asked them to run a PowerShell command. Huntress traced that command through an installer and a multi-stage payload chain to a remote-access trojan.

The practical lesson is narrower than “don’t trust AI.” A trusted platform can host user-created content, and a verification page should never need a person to paste a command into a terminal. For detection, the join between browser activity, PowerShell, a downloaded installer, and persistence matters more than blocking a famous domain wholesale.

Ullrich also covers SEC Consult’s research into spoofing iCloud sender addresses through email-header parsing behavior, which the researchers say Apple has fixed, and a separate Proton Mail display-name homograph technique. They are different issues. One concerns sender-address handling; the other concerns visually similar characters in a name shown to the reader.

For a payment change or urgent access request, the display name should not be the deciding evidence. Check the full address and message context, and confirm the request through a known channel. That is a workflow habit, not a claim that every unusual name is malicious.

1. 1

   Know your approved remote-support paths. Inventory the tools and instances your helpdesk actually uses. Review unexpected client installs or outbound sessions against that list, without treating every support tool as hostile.

2. 2

   Correlate the handoff to execution. Look for a browser or chat interaction followed by PowerShell, an installer from a temporary path, and new persistence. Preserve the page and command if a user reports a fake verification prompt.

3. 3

   Add a human check for high-stakes email. For money, credentials, or access changes, verify with a previously known contact route. A display name or apparent sender domain is only part of the evidence.

This is Threat Field Notes’ original reading of the 2 October SANS Stormcast and the research linked by the episode. The four items are separate cases, not one campaign. The investigation suggestions are our defender takeaways, not quoted instructions from the host.