Does EMET Dial-Out A Lot?

Well I just kind of said it rhetorically, but really everyone in this thread did help me... helped reinforce why I like where I'm at and am in no hurry to change anything.

This, combined also with hearing recently about how MS put a backdoor into AppLocker... these things serve as reminders to me. And I cringe just thinking about how some people on 7/8 put their trust in 1'st party tools only to keep them safe. And just imaging what other info. may be leaking out of things like svchost & service.exe, which they force you to allow to leak for your OS to function, along with 30+ other services. Who knows what may be seeping out with those packets?...

More secure out of the box, without question, but at what cost?... probably a ton of privacy. I can keep my privacy intact, and take measures to provide me with the security too with some tweaking & 3'rd party support. All things considered, I trust my XP setup much more.

People see system wide Smart Screen Filter as a good thing... I see more privacy being leaked. And now they're even giving out their OS for free (Blue) just to get people to "upgrade" and toss their info to MS. Everything about that feels shady to me.

If some day I realize I am vulnerable on XP and should change, I will, but it will absolutely NOT be to another Windows OS.

 

Looks like uninstalling EMET 3.0 trashed DEP on my WIN 7 SP1 installation. Luckily I checked the DEP setting yesterday and saw it was totally turned off. Could not reset via the WIN 7 DEP tab so had to use bcdedit to turn it back on.

I am still getting those svchost.exe hotmail.com dial outs though. Always IP addresses 64.4.11.42 or 65.55.57.27. So I have tightened up my firewall DNS and IE9 rules in NIS 2013. So far so good.

These dial-outs I suspect are related to llmnr port 5355. What I hate about WIN 7 is it uses llmnr as a backup to regular DNS. If it can not connect using UDP port 53, it will use UDP port 5355. Why MS did this in WIN 7 is beyond me. My next step is to flat out block all UDP port 5355 traffic outbound.

 

Do that and it'll find another way out... or just block your internet connectivity altogether and/or break Windows in some other way. This is a disgrace... I'm so glad I don't have to deal with stuff like this on XP, and hearing these stories always reinforces to me why I stick with it. Things like svchost & services.exe... I have no idea what those packets are they're sending out. And I don't need to allow it here on my box for it to function and take that risk.

So you uninstalled EMET but it is STILL dialing out? That's ridiculous! And you remove it and it takes DEP along with it, lol... like: "I'm I'm goin, I'm takin you down with me!"

With software like this... who needs malware? This is making my choice quite simple for me personally. I am not putting EMET or .NET FW on this new box I got. I'm settle for Hardware DEP (Always On), set through my "System" > Advanced. And the shellcode injection protection Comodo FW/D+ provides which is similar to what ASLR & do. That and keep my attack surface miniscule in the first place by disabling all services, processes & whatnot I don't need. Closing up associated ports. Not using things like Java, PDF programs, .NET Framework (it giveth & taketh away exploits), and Javascript via NoScript as well. I have enough in place already to help me against exploits without having to make a concession like this. This is a perfect example of the "concessions" I spoke of regarding these newer OS's and their shiny new tools they bring with them.

I recommend turning DEP to Always On in your OS settings, and having some app (normally an outbound FW/HIPS program) with buffer overflow/shellcode injection protection. Comodo FW/D+ has such a thing, and I'd think most would these days. If you don't have an app that possesses such a measure, and/or are an inbound FW only type, then WehnTrust may be worth looking into for you. Lessen your attack surface like I said. If you don't use Java, or PDF, and have your browser well hardened, even Sandboxed, there aint much an exploit can do to you anyway. I even have Adobe Flash Player installed in a sandbox too.

And maybe keep an eye out for Exploit Shield when it's ready to go final/public too. I know I am. I've officially lost my stomach for EMET now after hearing about this.

 

There's also a member in here working on an EMET-like tool, essentially the same thing, that doesn't require .NET FW to run and that isn't shady and phoning home. Man, if they were ever to complete the thing... it would be like the most awesome security tool not named Sandboxie. Being able to take advantage of the mitigations without adding a potentially vulnerable framework to your system in the first place... and having it phone home. Having your cake and eating it too. That's the thing that always bothered me about EMET. It's like... here's this neat tool that will ward of exploits. Only, to have it, you must run it on top of this framework that has been exploited time & time again in the past. So you wonder if you're not just better off without either.

If he could bang this thing out I could have my cake and eat it too. That would be so awesome... no concessions needing to be made here. I'd so donate $ and encourage others to as well if he got it done.

 

More progress.

The culprit dialing out to cltdl.windowsupdate.com is TurboTax's updater service aka IntuitUpdateService.exe. I blocked it in the firewall and it appears the sucker will still try to worm its way out via svchost. So I disabled the service and that appears to have done the trick. No clue as to why it would connect to the above domain but I definitely didn't like it.

BTW - I had disabled update checking in TurboTax previously. Just another example of cloked spyware. Soon as I get my tax refund, I will uninstall TurboTax.

Not really surprised by this. The free ver. of TaxAct from H&R Block I had used in previous years dumped all kinds of crap on my PC.

Might give EMET 3.0 another whirl.

 

So you're saying that it wasn't really EMET at all then?

 

Well considering a few other people verified that EMET's notifier dials out on their boxes as well... one claiming the activity stopped once they disabled the notifier. Makes it hard to dismiss, even if it wasn't the case for that 1 person.

But then with svchost, you just never know exactly what it's doing... what's tied into it, etc... Everything about what exactly it is or does is very vague, and I don't like that. I like to know exactly what things are and what they're doing on my box. If I don't, they don't run, period. Because of this I just couldn't sleep at night with a svchost.exe or services.exe leaking through my firewall.

Those mitigation techniques I'll probably never need anyway aren't worth that pricetag to me. And if you insist upon using EMET, I'd at least disable the notifier for sure.

 

Hi L;

You know my view of syshost it is more harsh maybe than yours!

On Turbotax ( I'm stuck with it for the moment as well) it doesn't have a digital signature and leaks like a seive as the poster here has found out.

But as this thread is about emet leaking/dialing whatever word we want to use I thinking about a thread here on "what leaks" we would need /want evidence like FW logs to "accept" or take seriously We could then build a leak list!

What do you guys think?

 

Appears so.

However I have installed Exploitshield and I like it a lot. Absolutely no conflicts with NIS 2013 at all. EMET 3.0 and NIS 2013 were always fighting each other at boot time. I don't have that issue with ExploitShield since it is just protecting my browser.

I presently have WIN 7 svchost.exe locked down to win updates urls only.

 

Mine was signed. However appears the turkey installed a bunch of tracking crap that none of my security software caught. I got rid of it using IE9 Privacy clear sites tab.

 

FWIW, I've seen (in several versions) the Intuit Update Service become re-enabled. I think if you disable it, then subsequently allow the TurboTax application to check for updates, the latter will start the service and set it back to automatic startup. There could possibly be other scenarios where it re-enables it as well, I never tried to nail it down.

 

Think I finally found the culprit.

Dial-outs from svchost.exe to ocsp.web.aol.com. Also when these occur, there are dial-outs to www.microsoft.com but the IP addresses are the ones used by hotmail.com that I mentioned previously; 64.4.11.42 and 65.55.57.27.

Very little info available on ocsp.web.aol.com. At first glance appears to be another cert. validation server but used with ocsp protocol cloud balony? But this guy looks like a rouge to me. After the initial blocks on it over an hour ago, have not had any further blocked log activity from the firewall.

 

that's odd. i had to play with netstat -n and netstat -b last night for reasons arround skype. I never saw emet notifier or service hosts files to appear in the netstat -b listing. I have the same ip's connected, but they are related to skype.exe on my netstat -b listing.

 

IP Addresses Report



Created by using IPNetInfo

Order 1 IP Address 64.12.128.4 Country USA - Virginia Owner Name America Online From IP 64.12.0.0 To IP 64.12.255.255 Contact Name America Online Address 22000 AOL Way
Dulles
Email domains@aol.net Abuse Email abuse@aol.net Phone +1-703-265-4670 Host Name ocsp.web.aol.com Resolved Name ocsp-vm01.evip.aol.com

 

Looks like I have come full circle on this topic. No so much by choice I might add.

I have completed my detail monitoring of svchost.exe and have not observed anything security wise to be concerned about. What I have leaned from this exercise is that trying to have your firewall monitor svchost.exe TCP dialouts in WIN 7 is akin to Chinese water torture Everything from the OS dialouts. CRLs, PGP, and infinite WIN statistics and troubleshooting. My take on hotmail.com IP connects is MS has changed the way it downloads CRLs. In reality, these dialouts did start after the last WIN updates monthly updates.

I am also back to using EMET 3.0; not by design I might add. I posted in the ExploitShield .9 thread what happened: https://www.wilderssecurity.com/showthread.php?t=344265&page=2. Interestingly due to the WIN 7 startup repair and restore, EMET 3.0 is running great. I have also not noticed any dialouts from EMET notifier to date. Go figure.

 

Here's an interesting tidbit for those that have installed Turbo tax. Somehow the installer suceeded in creating WIN 7 inbound and outbound rules for the updater. What makes this a big deal is I use NIS 2013 and the WIN 7 firewall I thought was disabled as far the private and public profiles go. Appear the updater has a way to get around the NIS 2013 firewall.

 

Anything interesting to report on the bolded front? Like something you tried to stop but couldn't?

 

I suspect that NIS, Comodo, and any other third party firewalls that support Vista, 7, and 8, allow the Windows Service Hardening(WSH) firewall to handle all svchost.exe inbound and outbound requests. The WSH firewall still runs even if the Windows firewall is disabled. So when you run the WIN 7 trouble shooters, svchost.exe is using a bunch of services to dial-out to multiple MS servers. Hence the default rule in most third party firewalls to allow all outbound TCP port 80 and 443 traffic from svchost.exe. There is a security issue here though since software developers can update WSH rules to support their application services. I hope that Windows only allows access to WSH firewall registry entries, etc. by proper authentication, certificates, etc., but not sure.

 

now you're starting to see the bigger picture of overall computer security/privacy... good for you. Continue in this way...

One can account for less integrated tools (that are now being found to possess backdoors anyway), mitigation techniques, and even a weaker kernel with 3'rd party tools & a ton of tweaking/know how. And not only survive but thrive this way, malware free all your years. And use that OS knowing you don't have to compromise your privacy in return.

For you can't take the other OS and account for the fact that you must allow vaguely defined service(s) to leak through your firewall, sending God knows what to God knows who for it to function.

Under which scenario do you feel safer/more secure overall? Easy answer for me... but to each his/her own.

 

I guess I better read-up on that before a transition to Windows 7. In a way it sounds promising, in the sense that there continues to be a "more svchost aware" component that could filter things. Is there a way for the user to control this "Windows Service Hardening firewall" when Windows Firewall is disabled? Can third-party firewalls make use of it to gain greater visibility/control WRT svchost.exe "clients"?

I take it you've looked and found no way to configure things so that the user remains in the loop and can prevent/approve such application driven hole punching?

 

I know that it is not advisable, but has anyone tried to modify WSH rules through registry?

BTW, besides WFN's "Rules" section, is there any other way to view these rules in a more user friendly format?

 

I guess I should add as long as the WIN 7 firewall service is running. Disabling that is definitely not recommended.

 

I have a dream that someday we will not need :

1) to ever update an o/s it will be in the h/w and immune to manipulation
2) sandboxes
3) anti virus software free or paid
4) routers to hide behind
5) defrag
6) even backup
7) no calling home emet

All I need is a white list of sites I use that are 100% clean forever and don't spy on me.

Well Mrk? where are you when needed?

 

This confirms the svchost.exe connection to MS crl servers using an auto updater to update certificate revocation list. Appears auto updater is built into the crypto service. Also interesting read how MS was culpriable in the past Flame attacks. I still question why MS is using hotmail servers for this.

http://threatpost.com/en_us/blogs/microsoft-releases-automatic-updater-certificate-revocation-lists-plans-invalidate-short-rsa-k

 

Not possible. Only though a C++ program or a VB script.