Recently i have installed comodo firewall and comodo dragon and i have noticed that uns.exe try to connect to a remote ip address (178.255.87.3:448) at every windows startup.
The IP seems to be related to comodo group’s. I would like to know why uns.exe, that belongs to “intel management engine component”, try to connect to this specific IP.
Can you help me?
Can you confirm that uns.exe that runs on your system belongs to Intel management engine and not a malware? Please read UNS.exe Windows process - What is it? for reference. This may also be a useful post about it.
The port number is linked to DDM-Remote DB Access Using Secure Sockets Protocol. It is not a commonly used port but from the description I found it supports a service to access remote databases over a secure socket.
The IP address as far as I could find does not belong to Comodo but to a UK web hosting company called CCANET Limited. What makes you think that is linked to Comodo?
It looks like this Intel tool connects to a database using a secure socket.
I have ran a complete scan with avira and malwarebytes and they didn’t find any malware. I think that this IP is related to comodo because the address showed by whoisip corresponds at Comodo CA Ltd address (Unit 7 Campus Road Listerhills Science Park, Bradford) and here Networktools: whois 178.255.87.3 - Reverse IP Lookup, Whois, Ping, RBL Check, DNS Records, Traceroute, Host information is written that the route 178.255.80.0/21 is registered for Comodo’s group.
Also, like i said, this alert appeared after installation of comodo firewall and comodo dragon. I’m not sure if it’s related to one or both these softwares, but all info that i have found are related to comodo
Try to block it using Comodo Firewall, and see what happens, I would personally block it
If you have no use of Intel AMT, which is embedded with some Intel motherboard and allow SysAdm to take control of workstation in an Enterprise configuration, you can disable the 2 related services. AMT User Notification Service won’t no more be able to try to connect.
You can also disable AMT in the BIOS. You’ll find a good explanation on how to proceed in this document of Dell support http://support.dell.com/support/edocs/systems/latd630/en/amt/MEBX.htm
I have blocked this connection from the start. I can unistall intel program, but don’t explains the problem and the source of this strange connection attempt
Update: i can confirm that the IP is related to comodo dragon. I have uninstalled comodo dragon and during this operation comodo firewall asked me an outgoing connection to the famous IP 178.255.87.3:443 for the library certsentry.dll
Now still the question: why comodo dragon use UNS.exe for a remote connection?
I used cqcounter whois and got slightly different information. Hence our different outcomes.
I do see a discrepancy between your first and last post. In your first post it about port 448 and in your last post it is about port 443. Unless there is a typo it could mean we could be looking at two different phenomena both targeting the same IP address.
Did uns.exe disappear from your system after you uninstalled Dragon? Do you have the mentioned Intel helper program installed?
The discrepancy regarding port is a typing error, i have checked firewall log and the port is 443 (https) in both cases.
Anyway the interesting thing is that a dll directly reconducible to comodo has tried to connect to the same IP during uninstall procedure.
I have boot pc 3 times after uninstalling of comodo dragon and i haven’t see new uns.exe message, anyway i want to take some more time to be sure about this.
The intel service is still running but only local, it hasn’t any active connection (I have checked by msconfig and by task manager and comodo firewall).
If the ip is not related to comodo (strange), but dragon try to connect to this ip with uns.exe and with certsentry.dll, i think that there is some problem. I have downloaded the browser from the comodo site, is possible that someone has put a infected version in the download page?
Thanks for clearing that up.
Anyway the interesting thing is that a dll directly reconducible to comodo has tried to connect to the same IP during uninstall procedure. I have boot pc 3 times after uninstalling of comodo dragon and i haven't see new uns.exe message, anyway i want to take some more time to be sure about this. The intel service is still running but only local, it hasn't any active connection (I have checked by msconfig and by task manager and comodo firewall).I think what you are seeing is certsentry at work. Please read more about it in Certsentry preview topic. Certsentry was added to Dragon v18. So each time a program, uns.exe f.e., opens a connection to a secure server certsentry will also do its thing.If the ip is not related to comodo (strange), but dragon try to connect to this ip with uns.exe and with certsentry.dll, i think that there is some problem. I have downloaded the browser from the comodo site, is possible that someone has put a infected version in the download page?
Also there is nothing fishy about your download from the Comodo pages.
As to the problem with the IP addresses. The online databases about what IP range belongs to who are not always well maintained so you may not always get the right information or different information from different sources… :-\
certsentry.dll has tried to connect to the famous IP only one time, during dragon uninstalling procedure, instead uns.exe has tried to connect to 178.255.87.3:443 at every windows boot. Now, after some boot, i can confirm that after uninstalling of dragon, uns.exe hasn’t tried again to connect to 178.255.87.3.
Here a part of my comodo log: ImageShack - Best place for all of your image hosting and image sharing needs
I doubt that the origin of connection was uns.exe, because uns.exe is still installed and running like local service, like before, the only difference is the absence of comodo dragon. As the same way the strange connection appeared after installation of comodo dragon (now i know that was comodo dragon and not comodo firewall) and not before.
Regarding ip… yes, can be a mistake, but with all other coincidences is difficult to think that this problem isn’t related to comodo. Maybe is a trusted procedure, i don’t realy know what uns.exe was doing but i would like to know it.
As far as I understand when a program makes a secure connection certcentry will kick in. With Dragon uninstalled certcentry will also be gone.
When active Certsentry will be loaded in every process:
For me that explains why uns.exe would connect to the Comodo server.