Wrong Place, Right time - encryption

[RSexton]

My apologies should this waste anyone's time.
I am not a programmer, but have very basic programming background dating back to the Commodore 64. Time has evolved me into a Network Administration role that also includes some network engineering. I'd like to say I have more work than I can handle but that is not the current case and is another topic.

The problem is that I have been exposed to Ransomware several times now. Not on my own machine but on other people's and on networks I am responsible for. The infection seems to be called RansomWall where the first time it was version 2 and this last and most recent is version 3. Anyone following this topic knows that each version is more powerful.

From what I have read (all online sources) this infection uses the built in Windows tools to actually perform the encryption of user data / network (mapped drives) data.

Wanting reasonable efforts to prevent this infection I personally un-registered the DLL files registered on my windows 7 x64 Professional box that start with CRYPT*.dll. My problem is that I am not a crypto person and have not been able to locate authoritative answers on what this will do on my machine. I suspect it will break something and I've been running this way for well over a week now, but have not restarted my machine since doing this. I have however, done this on the last machine to get infected where I had to MANUALLY reload the box by hand. The hard drive was replaced and I still have the infected drive, but it was in the background calling home as several MSIExec's and CMD processes were running in the background anytime there was a working internet connection. Kill the internet connection and they would not fire up and those that were running would stop. Clearly this was doing much more than encrypting data.

I am here from this link listing this site where I hope there are some crpto experts that can chime in: http://www.w3.org/TR/WebCryptoAPI/

I am aware of other toolsets (whitelisting) that can prevent this exact infection but implementing those can be more problematic. So the question here would be what does unregistering those dll files break and more important would doing so prevent having user data encrypted.

I created a batch file to unregister the dll files from performing a dir cyrp*.* and of course when running it, many of them were not registered. So I modified the batch to exclude those and used that file to create another batch that would register them in the event I needed them in the future. The un-register batch looks like this:
:: RegSvr32.exe /u crypt32.dll
:: RegSvr32.exe /u cryptbase.dll
RegSvr32.exe /u cryptdlg.dll
:: RegSvr32.exe /u cryptdll.dll
RegSvr32.exe /u cryptext.dll
RegSvr32.exe /u cryptnet.dll
:: RegSvr32.exe /u cryptsp.dll
:: RegSvr32.exe /u cryptsvc.dll
RegSvr32.exe /u cryptui.dll
:: RegSvr32.exe /u cryptxml.dll

I did do the exact steps on the last infected machine which is XP x32 Professional. However, this machine is slated for a hardware refresh and will soon be replaced. I'd like doing this on every machine I am responsible for and including those of friends and family, but don't want to create additional work from breaking other items, or at least have a list of things known to be broken should this prevent that infection and those like it.

The absolute worst thing about this is that the authors of this infection will be able to see this information (should it work) and start developing a work-around and the wheel will need reinventing for protection. I'd really love having a global block list that could be implemented at the corporate firewall, but this does not help friends and family. It's really a shame we have to spend so much time and effort on stuff like this as those creating this stuff are quite talented.

Looking forward to any responses.
Thanks,
Robert

[RSexton]

For anyone following this topic (feels like none): I have updated information concerning the XP machine. Yesterday I had to re-register those DLL files and reboot so that the machine could "sync" license data online with Intuit for a new installation (upgraded) of QB Pro 2014.

I have not yet gone back and unregistered those dll files, but I am feeling like keeping them as not registered may be a good proactive route.

Also on my own machine (still has not been rebooted since unregistering them) I was not able to visit a site. I tested the link from another machine and it came right up, so I do suspect unregistering these dll files WILL create problems.

[JAB Creations]

Greetings Robert,

I visit several times a week to clean out the spam and I'll answer a thread if it's relevant to something I can help with directly and I have the time to contribute.

If you're looking for quicker responses I would try http://superuser.com/; people post here every-so-often. The thread view count exceptionally likely counts search engine hits though there are some humans around.