I have been seeing some weird connections TCP port 80 from svchost.exe that I didn’t like.
So I created a firewall rule for svchost.exe to allow LAN in/out, Localhost out, DNS, DHCP, port 123 to time.windows.com, and block everything else.
I also moved my svchost.exe rule below Comodo’s generated Windows Updater rule.
Now I am seeing all these tcp port 80 connections from svchost.exe being blocked. I expected a few but not this many?
[attachment deleted by admin]
Most of the connections look normal, but you should try to find out why Global Crossing and especially Beyond The Network America are being contacted. Ideally, You should find out which instance of svchost and thus which individual service is making the connections.
find out why Global Crossing and especially Beyond The Network America are being contactedThose two also caught my eys.
I have run WIN 7 resource manager after determining a svchost.exe PID to investigate without much success. No suspicious modules being used, etc.
I am begining to believe that MBAM Pro has some serious problems of late. Most seem centered around their update servers and what goes on after an update. For starters i have a “double” updating occuring; the second starting less than a minute after the first. Only one I previously observed doing that was Emmisoft Anti-Malware when their servers connect to Ikarus servers for additional definition updates. In that case Emmisoft informs the user this activity is occuring via an update status shown on the Anti-Malware GUI.
Appears to me that WIN 7 is worse at crypic diali-outs that XP ever was.
I wish Comodo would enhance the firewall to control process spawning like Sophos and WIN 7 firewall allows.
Did you identify which hosted service is making the connections?
No. I will have to turn on logging and examine each connection.
My own opinion is you cannot trust even legit applications these days. What Comodo needs develop is Internet+ and provide an IIPS - Internet Intrusion Prevention System …
There are a number of applications, such as those from Adobe, that use BITS, a hosted service, to perform updates. Perhaps you ha such an application installed…
As I expected, I think I had a bad MBAM installation.
I didn’t mention it previously, but I had originally installed the trial version via download. I subsequently bought the boxed ver. and activated the downloaded ver. to Pro using the key from the boxed ver… Yesterday, I uninstalled MBAM Pro using MBAM Clean and reinstalled from the box CD.
Today at first cold boot for the day fired up TCPView and watched what was going on. BTW - I did change my previous Comodo svchost.exe firewall rule to allow TCP out ports 80 and 443 with logging. More on this later. Anyway I did not see any malformed dial-out from svchost.exe to 24.xx.xx.xx IP that I had seen in the past after the MBAM def. update. Nor was there any DNS Client timeout entry in my event log.
Now for the interesting part. I did see a connection in TCPView for svchost.exe outbound, TCP port 80 to IP 209.18.42.81 right after the MBAM update. I had observed this connection previously. TCPView Whois resolved to some outfit in CA that does anti-threat protection. Looks like in was a connection through a Time Warner Roadrunner backbone.
Now the real interesting part. There is no entry of this connection in my Comodo firewall log. As mentioned previously, logging is on for TCP outbound ports 80, 443 for svchost.exe. My svchost.exe firewall rule terminates with block and log all IP in/out. My global IP all outbound rule has logging enabled.
Looks like this connection slipped right by the Comodo firewall?
As far as I’m aware, there’s no relationship between MBAM updates and svchost connections. When I update MBAM it connects directly to one of two CDNs in Europe - I’m not in Europe.
With regard to the 24 address, did you mean 224.0.0.252 or is this something different?
If the DNS errors are ID 1014 and 1006, they are very common. A quick search will provide links to copious amounts of information without definitive answer. It’s likely a problem with the DNS server timing out. It also doesn’t matter whose servers one uses.
Now for the interesting part. I did see a connection in TCPView for svchost.exe outbound, TCP port 80 to IP 209.18.42.81 right after the MBAM update. I had observed this connection previously. TCPView Whois resolved to some outfit in CA that does anti-threat protection. Looks like in was a connection through a Time Warner Roadrunner backbone.
You still need to find out which hosted service is making the connection.
Now the real interesting part. There is no entry of this connection in my Comodo firewall log. As mentioned previously, logging is on for TCP outbound ports 80, 443 for svchost.exe. My svchost.exe firewall rule terminates with block and log all IP in/out. My global IP all outbound rule has logging enabled.Looks like this connection slipped right by the Comodo firewall?
Are you still using the default Windows System Applications rule, if so, is it above your svchost rule?
Hello DonZ:
I believe it’s quite remote that your first download from CNET was corrupted or contaminated. However. let’s leave that possibility open. In the future, before executing the installation file, please upload the installer file (mbam-setup) to Virus Total and check for VT member endorsements, digital signatures, and hashes. If the endorsements and signatures are present, please consider checking the hashes against the previously published hashes. If all agree the possibility of a bad installer file are much too mathematically impossible for our practical purposes.
If CNET had been delivering corrupted/compromised MBAM v1.51.1.1800 installer files (their tenth most popular download), the number of user suspicions would have exceeded one by now and AFAIK it has not. IMHO the IP addresses you mention have no known relationship with Malwarebyte’s Content Delivery Networks.
At some point you may wish to Wireshark trap/record the exchanges you suspect and submit for scrutiny.
As remote and distasteful as it may seem, I would not completely rule out an ongoing infection in your own system though chances seem quite low.
HTH
With regard to the 24 address, did you mean 224.0.0.252 or is this something different?No. I was refering to IP addresses in the 24.143.196.00 - 24.143.196.99 range. You can read all the details at a thread I opened on the MBAM forum: http://forums.malwarebytes.org/index.php?showtopic=93120 .
Are you still using the default Windows System Applications rule, if so, is it above your svchost rule?I specifically made it a point to ensure my svchost.exe rule was above the default Windows System Applications rule. I will double verify this connection later this afternoon when I log on my home PC.
I haven’t downloaded CurrPorts yet. Will do that today and see if it’s logging feature can see what sub-process is dialing out. I have a feeling all the log will show me is that svchost.exe dialed out? I have checked out svchost.exe PIDs on previous occasions and I have not seen any suspicious sub-processes running.
As far as the other posters comments on CNET, fine - that’s your opinion. My opinion of CNET based on long exposure to its web site is to avoid it like the plague.
If CNET had been delivering corrupted/compromised MBAM v1.51.1.1800 installer files (their tenth most popular download), the number of user suspicions would have exceeded one by now and AFAIK it has not.Are you really sure about that? Have you read the recent postings on the MBAM forums from individuals having problems with recent MBAM downloads? More than one has questioned the integrity of what they downloaded.
Interestingly, you now have two addresses pointing to Road Runner - 24.143.196.x and 209.18.42.81, which is a bit of a coincidence.
If you’re going to try and use Currports to capture a log, you’ll need to modify the log settings:
File/Advanced Options/Use a custom Log Line
At the least you’ll want to add %Local_Port_Name% and probably %Process_Services%
With regard to the post on the Malwarebytes forum, You said:
Note that the IP address is a RARP of 224.143.196.66
RARP is Reverse Address Resolution Protocol, which is a protocol used to translate a hardware address to a protocol address. Basically, it’s the opposite of ARP. When referring to DNS the term Reverse DNS is used. This is the process of obtaining the IP address of a domain.
No hard evidence has surfaced AFAIK. Anecdotal maybe. The answer is still to verify the installer file hashes before execution. BTW all of MBAM’s current dll and executable files, once installed, are also digitally signed and their hashes are verifiable on Virus Total
FWIW - About an hour ago, I downloaded the mbam-setup-1.51.1.1800.exe installer file from CNET and it was perfect.
For MBAM downloads I recommend FileHippo.com where appropriate. But still - verify. I do hope you keep pursuing the IP address in question. I too am quite interested.
I too endorse CurrPorts from NirSoft.net as sometimes it’s a bit easier to trap an IP address that’s elusive.
Good hunting. 
Interestingly, you now have two addresses pointing to Road Runner - 24.143.196.x and 209.18.42.81, which is a bit of a coincidence.Yes, I had determined that about the 24.143.196.xx address. I do beleive that address was a bogus DNS rebind attempt. I could never resolve it in TCPView's WhoIs with it showing as an unconnected endpoint. Accordingly, I don't think it has anything to do with Roadrunner.
The 209.18.42.81 however did resolve in TCPView’s WhoIs to a Roadrunner backbone server in Caliifornia. It actually noted a company name. I will post it later after I log on my home PC.
It is funny how I have received very little MBAM forum feedback on this issue. On past postings, they were always right on top of things.
Here we go again!
No dial-out to 209.18.42.81. Back to the original MBAM Pro behavior. MBAM definition update from 93.184.215.73 completes as expected.
Shortly thereafter a dial-out to 77.67.87.43. Mbamservice.exe starts running with corresponding HDD activity. No Comodo firewall log entry for svchost.exe dial-out to 77.67.87.43.
IP 77.67.87.43 is registered via RIPE to Akamai in the Netherlands. I reside on the east coast of the US.
See attached screenshot verifying the above.
“Houston we definitely have a MBAM problem here!”
[attachment deleted by admin]
Caught the 209.xxx.xxx.xxx svchost.exe dial-out on the second boot after an Avast boot scan.
Again no entry in comodo firewall for the dial-out.
See attach screen shot.
So are we ready to declare MBAM Pro spyware?
[attachment deleted by admin]
OK, figured out what is going on here. Best to leave it at that if you get my drift.
Would have been nice if MBAM would have PM me and saved me all this effort and exposure issues for them.
My main question is does Comodo let connects like this through the firewall by design and cloke it’s logging?
I will also have to re-evaluate whether I want to continue to use MBAM Pro since I don’t like what they are doing.
Again my motto is trust no one when it comes to computer software. I should know; I have been writing code for over 35 years!
I, and perhaps most everyone else, may fail to catch your drift. Please elaborate. Mistakes or incorrect conclusions are not fatal here or in the MBAM forums.
Would have been nice if MBAM would have PM me and saved me all this effort and exposure issues for them.
You were given the most extremely authoritative answers by MBAM upper management in your previous MBAM forum threads.
You were also asked for your logs. Perhaps you wished to pursue this more on your own. Still - the queries weren’t answered by you.
My main question is does Comodo let connects like this through the firewall by design and cloke it's logging?I will also have to re-evaluate whether I want to continue to use MBAM Pro since I don’t like what they are doing.
What is it exactly that MBAM PRO does that you object to? Please be precise. Your answer could be interesting to many.
Again my motto is trust no one when it comes to computer software. I should know; I have been writing code for over 35 years!
May we conclude that MBAM probably isn’t spyware afterall?
Isn’t MBAM really Anti-Malware?
Is the conclusion that you received a bad downloaded somewhat more remote now?
Please let the Comodo/MBAM forums know if they can help you in the future.
As I said earlier, I don’t believe there’s any connection between the MBAM updates and the svchost connections.
IP 77.67.87.43 is registered via RIPE to Akamai in the Netherlands. I reside on the east coast of the US.
AKAMAI is a massive CDN who provides resources for a great many companies, any one of whom could have an application installed on you PC. (See image for my Network zone for AKAMAI - I’m not in Europe or the US and this list continues to grow from svchost entries captured from the firewall logs)
My main question is does Comodo let connects like this through the firewall by design and cloke it's logging?
The fact that you’re not capturing the log entries does suggest a problem with your firewall rules.
Have you identified the hosted service responsible for making the connections yet?
[attachment deleted by admin]
Every trace of MBAM Pro has been wiped from my WIN 7 installation.
I am blocking all port 80 and 443 outbound from svchost.exe. If that interferes with auto WINUpdates, I will do them manually. If I need to dial-out for WIN help, I’ll deal with that also.
Presently my svchost firewall rule is right below the default WIndows Update Application rule but above the default Systems Applications rule.
If I still see any further unlogged outbound port 80 and 443 activity from svchost.exe, Comodo will also be the next to go.
All my outbound rules where a possible svchost outbound connection could occur are set to logging.