Jon Fulkerson
asked on
Preventing Ransomware in Macro Docs?
I have implemented a quarantine mailbox for email with attached documents that is managed by 2 trained staff. The intent is to prevent ransom-ware infection through macro enabled documents. I have been informed that this process is not well liked and it takes too long to get documents. Typically docs are forwarded on within an hour or less but sometimes can be a couple hours depending on staff availability.
Current Security in place
1. Barracuda Spam Firewall
2. Webroot Secure Anywhere (Previously Vipre Enterprise which did not catch the Ransom-ware)
3. Vipre Email Security for Exchange
4. KnowBe4 security training and phish testing regularly. (We still sometimes get 1-3% of people clicking on phishing links)
Am I being overly cautious? Should quarantines be managed by each end user instead of I.T.? (End users are the weakest link)
This came about because of a zero-hour locky outbreak a few months ago that took 12+ hours to clean up.
Any opinions appreciated. I do not like being the gatekeeper for everyone's docs in email and do not want our quarantine process to be a hindrance to business.
Current Security in place
1. Barracuda Spam Firewall
2. Webroot Secure Anywhere (Previously Vipre Enterprise which did not catch the Ransom-ware)
3. Vipre Email Security for Exchange
4. KnowBe4 security training and phish testing regularly. (We still sometimes get 1-3% of people clicking on phishing links)
Am I being overly cautious? Should quarantines be managed by each end user instead of I.T.? (End users are the weakest link)
This came about because of a zero-hour locky outbreak a few months ago that took 12+ hours to clean up.
Any opinions appreciated. I do not like being the gatekeeper for everyone's docs in email and do not want our quarantine process to be a hindrance to business.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
McKnife
If you manage to deploy software restriction policies or applocker in whitelisting mode (I hope you are famailiar with these terms?), then you don't need to worry about macros any more.
Also consider installing the paid for version of CryptoPrevent
You just pay a small once-off fee per machine (No recurring fee).
It's great for setting up white/black-listing policies Etc.
This screen also modifies the PCs Group Policy.
You just pay a small once-off fee per machine (No recurring fee).
It's great for setting up white/black-listing policies Etc.
This screen also modifies the PCs Group Policy.
@Eirman
Does CryptoPrevent even offer whitelisting? Looks like blacklisting.
Does CryptoPrevent even offer whitelisting? Looks like blacklisting.
It does whitelisting.
It seems good to me - What do you think McKnife?
It seems good to me - What do you think McKnife?
I don't see the point in using a 3rd party product in the first place when windows' own features allow the same. FoolishIT tried to help users by spreading their software together with a set of blacklistings back then. It proved to be better than nothing of course, but nowhere as effective as true whitelisting (anything is blocked but the whitelisted stuff). So to judge the product, one would have to look at their default setting, which defines "how to treat executable that are neither white-, nor blacklisted". How about that? (I don't use the product)
graylist should not run if we take by stringent rule of whitelisting - kinda of like anti-spam graylisting e.g. The idea behind graylisting is that any sender who has not previously sent a message to
the recipient, and who is not listed on a whitelist or a blacklist, is graylisted. This means that the sender
is not trusted until the message is proven to be trustworthy, but the sender is not immediately
blacklisted either.
the recipient, and who is not listed on a whitelist or a blacklist, is graylisted. This means that the sender
is not trusted until the message is proven to be trustworthy, but the sender is not immediately
blacklisted either.
Hi McKnife. This an extract from this article (Read on down for W10 Anniversary Ed. info)
Confusingly, the Professional edition of Windows 10 will allow you to create AppLocker rules using the Local Security Policy editor. However, these rules won’t be enforced unless you’re using an Enterprise or Education edition of Windows, so rules you create on a Windows 10 Professional PC won’t do anything unless you upgrade. This feature is was also found on Windows 7 and 8. On Windows 7, you could get it as part of the Ultimate edition.
I only hove Win10 pro, so what do you recommend?
--------------------------
@jonf805 - Sorry for semi-hikacking your question!
Confusingly, the Professional edition of Windows 10 will allow you to create AppLocker rules using the Local Security Policy editor. However, these rules won’t be enforced unless you’re using an Enterprise or Education edition of Windows, so rules you create on a Windows 10 Professional PC won’t do anything unless you upgrade. This feature is was also found on Windows 7 and 8. On Windows 7, you could get it as part of the Ultimate edition.
I only hove Win10 pro, so what do you recommend?
--------------------------
@jonf805 - Sorry for semi-hikacking your question!
Pro has software restriction policies, the predecessor of applocker. It is what foolish IT uses, too with their ruleset.
thanks
i assume disabling macros altogether or expecting the users to allow selectively the useful ones is not an option...
as far as locky is concerned, it usually commes as a jscript easily-identifiable file in the first place. jscripts are hadly ever found in conventional email, so if you can simply clean jscripts by file type, you'll get rid of a huge part of the locky problem. now this is obviously nowhere next to a complete security policy to prevent such threats but should help on the short term.
as far as locky is concerned, it usually commes as a jscript easily-identifiable file in the first place. jscripts are hadly ever found in conventional email, so if you can simply clean jscripts by file type, you'll get rid of a huge part of the locky problem. now this is obviously nowhere next to a complete security policy to prevent such threats but should help on the short term.
Locky had recently evolves with its variant, like previous variants, it is being spread through WS, JS, etc email attachments attached to SPAM emails. If a recipient double-clicks on one of these script files, it will download an encrypted DLL installer, decrypt it, and execute it using the legitimate Windows program called Rundll32.exe. Once executed, Locky will encrypt a victim's files, rename them, and then append the .ODIN extension.
So application whitelisting will be preferable to managed running only trusted scripts and DLL. Best not have user having admin right..
http://www.bleepingcomputer.com/news/security/locky-ransomware-now-uses-the-odin-extension-for-encrypted-files/
https://technet.microsoft.com/en-us/library/ee460947(v=ws.11).aspx
So application whitelisting will be preferable to managed running only trusted scripts and DLL. Best not have user having admin right..
http://www.bleepingcomputer.com/news/security/locky-ransomware-now-uses-the-odin-extension-for-encrypted-files/
https://technet.microsoft.com/en-us/library/ee460947(v=ws.11).aspx
yes. additionally, the files ( at least the js ones : i did not get to analyse samples of other ones ) always contain words that should be easily detected by any decent antispam software and should also be blocked by clam if PUA is enabled. note that clam won't block the downloaders otherwise as they legitimately consider them to be non-viral. commercial vendors will block the downloaders but tend to have a hard time to produce a generic signature for all loki versions so they will leak occasionally.
zero day prevention can only be achieved by whitelisting allowed applications. this can be done using GPOs and builtin windows security, with personal firewalls, and probably a bunch of dedicated commercial software. unfortunately it usually comes with a bunch of annoyed users.
zero day prevention can only be achieved by whitelisting allowed applications. this can be done using GPOs and builtin windows security, with personal firewalls, and probably a bunch of dedicated commercial software. unfortunately it usually comes with a bunch of annoyed users.
ASKER
Thanks all for chiming in. We have put in place insurance to cover us in the event of Ransomware or another attack. Backups are solid. Priveledges are not as tight as I would like due to AutoCAD requirements but the network shares are fairly tightened.