CryptoPrevent is no longer based solely on Windows software restriction policies

Yes, but what if you run it from the desktop. The point that I'm trying to make is, that it hasn't got any pro active malicious behavior detection. It's just trying to make it a bit harder for exploits to work, unless I'm missing something.

 

I downloaded Group Protection Policy and set it up on my Windows 7 Home Premium.

I disallowed writing executables to the App%Data folder malware like crypto software is known to execute to, so its pretty good.

All I don't have is Applocker but then you'd need an Enterprise edition to enforce rules made with it.

 

You're correct with regard to version 7. It's not enough by itself imho; I use HMPA along with it. Version 8 is coming soon though and the dev says it will be more better

 

Yes, and if you're already using anti-exploit and/or anti-executable, you don't really need it.

 

You can now install GPO on home versions of Windows and gain access to standard security policies through gpedit.msc - which couldn't be enabled before.

That now allows one to block writing executables to the %AppData% folder, that malware usually runs in.

Finally, you don't have to fret at Microsoft's stupidity in making it unavailable to home users.

 

Installing GPO on home versions definitely adds valuable functionality, but RE crypto-ransomware specifically there's much more being done by CryptoPrevent (CP) then just locking down %appdata% Have a look at the advanced editor in CP.

 

One does have to whitelist certain legitimate installer exe files and a few programs that run from the %AppData% folder.

They're supposed to write to the protected %ProgramData% folder but not all companies follow the rule.

 

Where can I find the installer for GPO?

 

You might find the discussion in this thread helpful. It also includes links for installing the Group Policy Editor in versions of Windows that don't already have it:

http://www.sevenforums.com/software...l-gpedit-msc-my-windows-7-home-premium-2.html

 

Thanks. I did find the setup utility for gpedit.msc. Long ago I had copied the GroupPolicy and GroupPolicyUsers folders plus gpedit.msc from the SysWOW64 folder to my Win 7 x64 System32 folder. Just ran the gpedit.msc setup utility and I now finally have it working!

 

Congrats Note that some people in the 7 Forums thread said that applying policies through gpedit.msc on Windows 7 Home Premium didn't always work.

 

On one of my boxes that i use most i have Windows 8.0 and been without the GPEDIT.MSC snap in since it's an OEM version.

Thanks for the sevenforums link. It's Working!

 

It would be interesting to know if restrictions set with gpedit specifically to block crypto-ransomware work when gpedit has been added to the OS after the fact.

 

About the only thing it won't have is AppLocker and VS is a good substitute for the latter in home versions of Windows.

 

You should be able to enforce SRP. You won't be able to enforce no-execution of executables because only Windows Enteprise offers it so you'll need a third party anti-executable.

VS should be a sufficient replacement for AppLocker.

 

Well i have to admit that the embarrasment was a bit more than i could take at the time (hence my earlier rant) but it taught me a very valuable lesson. And that is you can't take your attention to pc security from off your computer for very long before something even more devious than their predeccessors come along to ruin your comfort level. After all these years of pinpoint security precision only to get caught with your trousers down is a real eye opener. Was for me at least when i got slammed by mr crypto myself, no doubt from the proverbial drive by pop up. It obviously didn't help that i still run IE either.

At least now that everyone is fully aware of the newest intrusion malware theres finally some decent third party participants stepping up on stage.

 

In that case with regard to Crypto-ransomware why not just use CryptoPrevent since it creates SRP and enforces no-execution?

 

For those who don't want to set their own policies, CP is a good solution.

 

Yep. Just confirmed this locally. No matter, CP should do ok and ver 8 is soon coming up. I really don't expect to be caught off guard again in the same manner but just in case..........

Also Secure Folders DOES enforce no-execution of executables too. Just have to learn more of the basics of Bouncer/Secure Folders in order to shore up what needs it and where and hopefully prevent some redundancy between these too

 

Bouncer incorrectly configured, can lock one out of one's own computer.

I prefer Voodoo Shield, which is fool-proof and its default setting is more than sufficient for most home users.

 

Please explain.

The same is always held true for various third-party software gadgets, especially these security ones. Thanks.

 

Maybe I am missing something about cryptolocker, but HIPS rules should stop this in it's tracks. Creating equivalent "ask" %Appdata%\*.exe and %LocalAppData%\*.exe plus associated sub-folders will alert you to anything running in those folders. It is then easy to create "allow" rule exceptions for anything that is legit. I already have HIPS rules set up for \Run and \RunOnce registry keys among many other keys. Even without special rules, the HIPS using its default rules should detect any critical file modifications or changes in permission.

Also AppData folder exceptions should be far and few. I checked those folders and didn't find a single .exe in them.

Finally, any decent behavior blocker such as Emsisoft's Anti-Malware BB should also easily catch cryptolocker activity.

 

Which HIPS do you use? Also this may be of interest:

http://www.secureworks.com/cyber-threat-intelligence/threats/cryptowall-ransomware/

Excerpt:

"To establish persistence across system reboots, a copy of the malware is placed in %AppData%, %UserProfile%\Start Menu\Programs\Startup, and a directory at the root of the system drive. Then the malware adds multiple "autostart" registry keys (see Figure 7). Some CryptoWall variants also install a "RunOnce" key prefixed with an asterisk, which causes the executable to run even in Safe Mode. Each sample is configured to use a certain six hexadecimal character filename (e.g., 3e0d6a) that the malware uses in other variations (e.g., 3e0d6a9)"

 

I used Eset's Smart Security 8 HIPS.

The main point however is to stop this malware before it even gets into your system. To quote from the link you provided:

CryptoWall has spread through various infection vectors since its inception, including browser exploit kits, drive-by downloads, and malicious email attachments. Since late March 2014, it has been primarily distributed through malicious attachments and download links sent through the Cutwail spam botnet.

I use EMET 5.1 plus Eset's SS 8's exploit blockers. Eset's web filtering is pretty good against drive-by downloads. I use T-Bird's e-mail client and only receive e-mail in text mode so all attachments are listed separately. Eset also has excellent botnet protection. Finally, I use Emsisoft Anti-Malware to catch anything that Eset has not caught. To date, Eset has caught everything.

Finally, I always have ActiveX filtering turned on in IE 10 and only use FlashPlayer when absolutely necessary and only on a site I trust.

-EDIT-

Another quote from the referenced Dell link on CryptoWall:

It creates an "explorer.exe" process using the legitimate system binary in a suspended state and maps and executes malicious code into the process's address space.

So the primary infector is explorer.exe. Clever in that many exploit blockers have issues with explorer. Most EMET installations don't protect it per Microsoft's recommendations. Also it is common to have more than one instance of explorer running.

However, the minute the bogus explorer process is created, the OS knows about it. It doesn't matter if the process is in the wait state or not. At that time, Eset will inject it with it's shell.dll and Emsisoft the same with it's behavior blocker .dll. One of those will catch the code injection.

Additionally, since the created process is a legit version of explorer.exe, a HIPS rule for it could be created to check for any modifications to explorer.exe. Don't believe that is necessary though since explorer.exe is a system file and should be covered under the default HIPS rules.

Note: In the Dell example the bogus explorer process appears to only have admin privileges so I believe one of the above mitigations should catch it.

-Correction-

Appears HIPS rules at the process level will not help for "zombie" processes as noted below. Best approach for HIPS is to block any affected registry keys as noted in this McAfee article which by the way, shows dllhost.exe based malware with a potential CryptoWall payload: https://kc.mcafee.com/resources/sit...Afee_Labs_Threat_Advisory-Trojan-Powelike.pdf .

Zombie Processes

The concept of zombie processes is pretty simple: we can create a standard Windows process in a suspended state, then write our malicious code to the processes' memory; the PEB and the EPROCESS structures will still be that of the original process, causing the HIPS to see the now malicious process as a legitimate signed executable (this is not RunPE or dynamic forking, because we don't unmap the original executable and replacing it with our malicious one, as those can be detected in multiple ways). It's basically PE injection, but with less exposure to functions that would allow the HIPS to detect code injection. CreateProcess returns a handle to the created process and its main thread with full access, so we don't have to call OpenProcess or OpenThread.The main thread is in a suspended state and we know the entry point, so no need to call CreateRemoteThread. Modification to a child process is far less suspicious that a foreign one.

Injecting the Code

A common practice is to call VirtualAllocEx to allocate memory, then use the returned address to relocate the code ready to run at that address. Once the code has been prepared, it can be written to the process with WriteProcessMemory. This is a terrible idea, every HIPS ever expects malware to do that. A better practice used by newer malware (such as Andromeda and BetaBot) is to create as section, then use NtMapViewOfSection to map the section into both the current process and the target process. It's not really possible to know what address the section will be mapped at before mapping it, so this would cause a problem with code that requires relocation.

NtMapViewOfSection actually maps the same physical section into both processes (writing the map of the section in the current process will also write the map in the target process), we can simply map the section into both processes then relocate and write the code to the section in the current process, resulting in it also being written to the target process, no WriteProcessMemory needed!

ref: http://malware278.rssing.com/chan-21376777/latest.php