How to see what causes unwanted internet connections?

[test5362]

I'm seeing connection attempts via SSDPSRV and Firefox to activation.cloud.techsmith.com, related to Techsmith Camtasia which I have uninstalled a long time ago. It's also blocked via hosts file, but I would still like to get rid of this. I've already tried looking through all processes, services and deleting anything related in the registry, as well as running several different AV scans, but to no avail.

[mshultz]

Have you checked Task Scheduler?

[NotHereToPlayGames]

Beyond that, don't just look at Task Manager "Processes" but also look at the "Services" tab.

I forget if this is in Win7, but there is a "Open Services" link at the bottom of the Task Manager when you are in the "Services" tab.

You probably have an "updater" running as a SERVICE that just needs disabled.

[D.Draker]

19 hours ago, test5362 said:

SSDPSRV

That spammy service should have been disabled in the first place !  Always.

[msfntor]

Here is the very interesting topic, maybe I could be useful... I also think like ArcticFoxie, that "You probably have an "updater" running as a SERVICE that just needs disabled."
To see the processes, services running, there are several free tools on the web... and on the Taskbar of my old computer : first, look in "Event Viewer" ... then in "Services", then "SterJo NetStalker", CrowdInspect, CurrProcess, Tcpview, ProcNetMonitor, then scan with Malwarebytes Anti-Malware, AdwCleaner, PowerTool, use SpyDllRemover, WiseRegCleaner, DTaskManager, Process Hacker, then post your results here... Good luck!

 

[test5362]

Thanks for the replies, I couldn't find anything in Task Scheduler either, and I rechecked the services and just can't see anything strange there, it's pretty much all standard Windows services. I did turn off SSDPSRV as I have no need for UPnP, I'm not sure why it was running anyway as revertservice claims the default setting for it is "manual". That did kill the UDP connection from that but it's still trying to connect via Firefox, and in fact it seems to try to connect right after boot, even before Firefox is launched.

I'm using tcpview and procexp so some of these tools are probably redundant (and CurrProcess only sees 32-bit processes btw) but I went through SpyDllRemover, MBAM and AdwCleaner so far and they found nothing relevant. I went ahead and changed the 127.0.0.1 IP in the hosts file for activation.cloud.techsmith.com to some random private range IP, then instead of connections to activation.cloud.techsmith.com tcpview would show 65.52.240.48. That was actually in the hosts file too but I looked that IP up online and got this: https://superuser.com/questions/729277/why-am-i-connected-to-65-52-240-48 and also this: https://support.mozilla.org/bm/questions/1302652

So basically confirming the issue but no solution offered. Procexp shows me the Firefox process that's doing this TCP connection but there seems to be no way to see what triggers this.

Edited April 22, 2023 by test5362

[NotHereToPlayGames]

5 hours ago, test5362 said:

but there seems to be no way to see what triggers this.

That's why none of my systems have a "default" web browser - NONE.

So when an "installer" tries to connect to the internet, IT CAN NOT because there is no "default" web browser for it to "go through".

You need a "parent-based" firewall - that will tell you EXACTLY what triggered your Firefox to make a connection.

I used to use an OLDER version of Commodo Firewall that was PERFECT for just this.

I'd have to dig though some archives to find it.

With a PARENT-BASED firewall, your Firefox is allowed access to the internet when launched via a desktop shortcut or via the start menu, but it is DENIED access if an "updater" launches it.

The firewall would also block a new tab from accessing the internet if you already have a properly launched Firefox open and that "updater" opens a new tab.

Then you would have the "updater" IDENTIFIED because the parent-based firewall would tell you the exact PATH of what launched it.

I suspect Nirsoft might have something to track the trigger also, unsure.

[msfntor]

6 minutes ago, NotHereToPlayGames said:

That's why none of my systems have a "default" web browser - NONE.

So when an "installer" tries to connect to the internet, IT CAN NOT because there is no "default" web browser for it to "go through".

Me too...

Edited April 22, 2023 by msfntor
added line

[kar1]

This unwanted activation check after removing all TechSmith software has nothing to do with any TechSmith update service, it's probably just because you didn't properly uninstall all leftover video & audio codecs from a commercial TechSmith program.

 

Therefore everytime a leftover full version of a TechSmith codec is initialized (for video playback or for enumeration of its capabilities) it becomes part of the process that tried to play a video or audio file.

And so you end up with firefox.exe trying to connect to techsmith servers.

 

The videohelp.com website has a good index of codec tools such as CodecTweakTool or Win7 DS Filter Tweaker to inspect this issue deeper.

 

GraphStudioNext cans also diagnose & manage video codecs & video filters.

There's even a dedicated section for this in SysInternals' Autoruns utility.

 

And none of any parent-based firewall will help to block this unless it also has HIPS features for blocking unwanted modules injection & loading within trusted processes.

 

If a firewall supports both parent/caller process inspection & HIPS it's all good.

 

Otherwise firefox.exe could be called by explorer.exe (both trusted) and yet you still end up with firefox.exe loading that leftover TechSmith codec everytime it wants your system to play a media file, which causes unwanted connections.

[NotHereToPlayGames]

Agreed.

I think Commodo has HIPS but I honestly do not recall.

 

(edit - I no longer use firewall or anti-virus - none, naughta, zip.  I did use Commodo Firewall for several years and it was [been several years] very fast and efficient.  But I grew to dislike even a fast and efficient "bottleneck" for my computer needs.)

Edited April 30, 2023 by NotHereToPlayGames

[test5362]

Thanks for the suggestion about those codecs. I got all of the mentioned tools and to be honest wasn't sure what exactly to do with most of them, but autoruns did show me two Techsmith codecs, which were vidc.tsc2 and vidc.tscc, with a reference to the SysWOW64 folder. I got rid of them alongside all the corresponding registry entries I could find. In total, the deleted files were: tsccvid64.dll, tsccvid.dll, tsc2_codec64.dll and tsc2_codec32.dll. After a reboot, I could not see any Techsmith in Resource Monitor, but as soon as I start Firefox, unfortunately that activation.cloud.techsmith.com connection is back.

Edited May 10, 2023 by test5362

[NotHereToPlayGames]

Does your about:config show the word "techsmith" anywhere?

[test5362]

Nope, nothing in there and nothing in about:support (which actually has a codec list) and plugins either.

[vinifera]

maybe Tcpview from sysinternals might help you more

sry

Edited May 10, 2023 by vinifera
x

[kar1]

Try using 'Win7 DS Filter Manager' to check out whether any TechSmith codec is still available as a DirectShow filter.

Something else that cans be done is to replicate the issue again with Firefox, playing a video, then using ProcessHacker to check the 'Modules' tab for the firefox.exe processes.

If it has access to any TechSmith codec it will have to load its module.

However another trouble might be the hosts file:

The Resource Monitor probably does a Reverse-IP Lookup for 127.0.0.1 anytime you try connecting to it.

So of you block both some known Firefox/Mozilla trackers and this TechSmith domain name with 127.0.0.1, when Firefox will try to ping its tracking domains the Resource Monitor will do a Reverse-IP lookup (PTR-record) for 127.0.0.1 that will give out the techsmith domain.

 

That's especially due to the way the hosts file is parsed, which wasn't really intended to contain multiple different domain names with the same IP address.

 

So I suggest removing the techsmith domain name from your hosts file then rebooting Windows.

This will make sure the DNS cache (in RAM) is cleared for all processes including the system ones.

 

Afterwards, once you no longer have any techsmith domain in your hosts file you could use NirSoft's DNSLookupView program to verify whether TechSmith domain names are really queried.

 

DNS-over-HTTPS isn't a problem since it's a separate native TechSmith codec within Firefox.exe that does the DNS lookups using standard Windows APIs.

 

Short summary:

You can try first Win7 DS Filter Tweaker to verify that there's no TechSmith DirectShow filter in the system anymore.

 

Then clear your hosts file and reboot Windows.

 

It will also be a good method to download and try out DNSLookupView by NirSoft to verify that firefox.exe is really requesting the techsmith domain explicitly or if was just due to the 127.0.0.1 line in the hosts file.

 

Finally downloading and trying out ProcessHacker by wj32 will help to verify that firefox.exe didn't load any Module from TechSmith.

(Modules aren't always DLL files, they can potentially be any PE file; .exe, .dll, .bin with explicitly exported functions.)