Does EMET Dial-Out A Lot?

Sorry for going slightly off topic but this has been addressed with this hotfix.

 

I am glad to say to have shut down all MS dial-outs except for the certifcate updates mentioned previously and win updates. Here's what I did on my WIN 7x64 Home Premium SP1 installation.

1. Uninstalled IPv6. Should have done that ages ago. My router is IPv4 only. I also beleive MS was dialing out via IPv6 even though I had previously disabled all the IPv6 to IPv4 tunnels; IPv6to4, Teredo, etc.

2.Disabled Win Messenger via GP Editor. I downloaded one of the fixes on the web that enables GPEdit on the Win 7 Home Premium version.

3. Added block rules in my firewall to prevent EMET notifier and GUI from dial-out.

 

Do you have UAC enabled? If you do, you may want to prevent C:\Windows\System32\consent.exe from connecting out. This little snitch goes unnoticed...

 

I have UAC set at max setting. I see no evidence of consent.exe dialing out. If it were, NIS would have created a firewall rule for it.

 

I remember when I was using Norton UAC, that caused consent.exe to dialing out.

EMET 3.0 doesn't use or ever used consent.exe on my system. EMET 3.0 GUI and Notifier never seen dialing out on my system.

 

Interesting... because I get to see the attempts with Windows Firewall with Advanced Security logging enabled (Event Viewer). TCPView/other also reveals it.
If I recall, Outpost Firewall also had rules to allow consent.exe out.

 

I now remember a thread in the NIS forums about someone complaining about consent.exe. I believe it was in ref to NIS 2012. I haven't seen any traces of it using NIS 2013.

EMET notifier and gui dial out to ctldl.windowsupdate.com as wrote in my original posting. Appears to do so at cold boot time only. I also have observed that it doesn't to it every day.

 

Understanding Windows Automatic Root Update
- http://unmitigatedrisk.com/?p=259

http://support.microsoft.com/kb/2677070

Maybe the above can clear things up.

 

This deals with how certs. are updated. I beleive everyone realizes that occurs on a periodic basis.

I saw this previously and checked it out. First this is a "fix" and as such would have to be purposely downloaded. I never downloaded it and have no win update history of it ever being installed. I theorize however that MS included this "fix" in one of the prior security updates.

I do still very much question why MS is using the hotmail.com IP address range for these crl. updates and why one of the servers it uses a lot is located in Uzbekistan?

 

Before you enter in a conspiracy theory note that Microsoft and many other IT giants uses mirroring services for which data is balanced accross thousands of different servers across the world. The typical example is the service provided by Akamai. So, it is not unusual to see weird locations....

 

consent.exe attempts outbound to Verisign Global Registry Services ip addresses. Maybe what's happening is that when attempting to elevate using UAC a signed application, consent.exe connects to Verisign to validate the applicatuions certificate? Just a guess. Remember, too, that you get a certain colored UAC prompt depending on whether or not the attempt to elevate a signed application results in a verified signed publisher, Windows publisher, or untrusted publisher.

 

61 posts on this subject and stilll going strong and no firm conclusion has been found.
If its that much of a concern and im not sure if anyone has suggested this,but maybe the OP should just uninstall EMET and be done with it rather than tying themselves into knots as to whether it dials out or not and this thread displays a severe lack of trust in the program and microsoft in general.

 

Seems like we're stuck on this consent.exe. Again, I have never seen it dial-out once. I have never seen it running on my on my WIN 7 installation period.

 

Aside from the boot dial-outs from EMET for update notification as noted previously, I have not seen any other evidence of EMET dialing out.

 

I am well aware that MS uses servers all over the world for that matter.

I still don't like connects via Belgium to servers located in Ubekistan. McAfee corporate AV software has on more than one occasion blacklisted that server farm for suspicious activity. You have to question the wisdom in maintaining crl lists in a location like that.

 

Well, that just can't be. consent.exe process is what makes UAC prompts appear.

You could easily see it being run, if you monitor Process Explorer/other whenever you elevate another application or some Windows system/maintainance tool that requires admin. privileges.

In my system, I press CTRL+ALT+DEL to elevate processes, which gives me a nice view in Process Explorer.

Anyway, consent.exe does run, or you wouldn't see any UAC prompts, at all.

If you have never seen it (consent.exe) being run, then something is wrong with your Windows 7 installation, I'm afraid.

 

Ok. You got me going on this consent.exe issue.

I fired up process explorer and then did something to trigger a UAC prompt. Two dllhost.exe processes appear in process explorer and immediately disappear.

I checked these dllhost.exes a while back. Was told this was COM running. I suspect that consent.exe might be triggered by these dllhost.exe but it is hidden.

 

With Process explorer open run the same test, but look for consent.exe spawned by a svchost process, probably with the command line "C:\Windows\system32\svchost.exe -k netsvcs"

It doesn't seem to dial out too often, but it has on my setup because I have a firewall rule for it configured off an alert I had a while back.

 

I don't know what ver. of Win you are using.

On Win 7, DCOM uses dllhost.exe to spawn consent.exe. However it occurs so fast, you visually won't see it. There are a number of postings on the web how dllhost.exe is used in conjunction with UAC.