The following is one experience in a global enterprise environment sent in by a reader.

=========

The following post is my experience with de-registering vgx.dll in a large, corporate and R&D environment with sites around the globe.

The purpose is to present our actions and findings.  I make no promises, guarantees, etc. that this will work for others. So please be sure to do your own testing and risk analysis.

All of that said ... I hope that my point of view helps to possibly aid others in their efforts to find and effective mitigation strategy for this vulnerability.

Since the early whisperings of exploits for the vulnerability, and then 'suggested' work-arounds, de-registration of the vgx.dll has been at the top of our list of possible mitigations.

Starting (very) early on Friday morning, and going through an 11 hour day, our InterOp team tested the affects of the de-registration on as many different system configurations as they could.  In the end they found no issues and supported this recommendation for mitigation.  Early Friday evening we put our plan in place and commenced with the de-registration of vgx.dll from all of our ~38,000 corporate and ~8,000 R&D systems.  By late-evening 1/3 of our targets had the dll de-registered; there were no reported issues with business critical systems and applications, there were calls to the help desks and there were no issues from our R&D folks.

Two and a half days after putting the plan in place 98% of our systems have had the dll de-registered and things remain stable and quiet on all fronts.

There have been some reports of system slow-downs by employees but after investigation there no clear linkages between the actions taken and the symptoms observed.  In most cases a simple reboot solved the problem.

We continue to monitor the situation as well as staying in contact with Microsoft to ensure that our environment remains stable and malware free.

=========

Thanks for sharing Eric.

Cheers,
Adrien de Beaupré
Cinnabar Networks/BSSI