Ransomware
-
@aaronstuder said:
@Jason said:
https://www.carbonblack.com/ they are good for executable whitlisting. Though a developer there once had his computer compromised by not having the software installed, and got malware pushed out with the product because he didn't tell anyone. But let's not talk about that haha.
What's something like this cost? Looks to be expensive. No pricing on the website is a bad sign
It's not crazy expensive. Configuring it takes a while. It's not AV. It is a Whitlist only/Default Deny package.
-
@Jason Thanks!
-
@Jason said:
@aaronstuder said:
@Jason said:
https://www.carbonblack.com/ they are good for executable whitlisting. Though a developer there once had his computer compromised by not having the software installed, and got malware pushed out with the product because he didn't tell anyone. But let's not talk about that haha.
What's something like this cost? Looks to be expensive. No pricing on the website is a bad sign
It's not crazy expensive. Configuring it takes a while. It's not AV. It is a Whitlist only/Default Deny package.
I definitely love the idea of white listing software. How does it handle things like infected Word documents? I think it would have killed Lockie because Lockie downloaded a thirdparty software package and then executed it, so that would be prevented.
Next the virus writers will start creating a Turing Complete setup inside the foothold they get, allowing them access to anything they want. - though maybe I'm completely off base on this.
-
@Dashrender said:
I definitely love the idea of white listing software. How does it handle things like infected Word documents? I think it would have killed Lockie because Lockie downloaded a thirdparty software package and then executed it, so that would be prevented.
It's not AV. Your AV should be the primary defense on that one. You could block Word.exe, the word/office HASH (so even if word.exe or whatever was me.exe it would still be blocked) or you can block the all .doc/docx files or the hash for one of these.
Your AV should really be handling the signatures. You can easily block powershell hash for users though and prevent a lot of those since they tie into powershell or CMD a lot of times.Or you can get more specific with it and say, that if X application (or hash) launches from word (or HASH) to not allow.
Here's some info on that:
-
In my previous post, I basically walked through my whole thought process from problem to solution, which I outline again below.
being specific is only good after you know about the badness.
Whitelisting is good because you only trust things you know are good.
Back to lockie - sure, you'd love your AV to kill this - but zero day exploits just slip right by AV. Why would I look at blocking Word.exe? or block all .doc/.docx files? my users need these for their day to day operations.
As I mentioned, I think the white list would still completely solve this because, when you open the bad Word document, it goes to the internet, downloads a file, and tries to execute that file.... but execution is prevented by the whitelist.
In a zeroday situation, the AV is definitely not going to protect you.
-
@Dashrender said:
As I mentioned, I think the white list would still completely solve this because, when you open the bad Word document, it goes to the internet, downloads a file, and tries to execute that file.... but execution is prevented by the whitelist.
No it doesn't If they wrote it all in VBScript as a Macro without using external things you can not block it with this solution without blocking office or word.
-
@Jason said:
@Dashrender said:
As I mentioned, I think the white list would still completely solve this because, when you open the bad Word document, it goes to the internet, downloads a file, and tries to execute that file.... but execution is prevented by the whitelist.
No it doesn't If they wrote it all in VBScript as a Macro without using external things you can not block it with this solution without blocking office or word.
Can an entire cryptoware solution be done purely in VBScript? If so, then disabling Macros seems like a requirement as a next step.
-
@Dashrender said:
Can an entire cryptoware solution be done purely in VBScript? If so, then disabling Macros seems like a requirement as a next step.
Good luck with that. Many people write their own macro's in excel to help with their jobs.
-
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
-
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
-
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
-
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
-
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
That's way different. Internal use vs sending them out. Sending them out is just as bad or worse than sending an .exe or .bat etc? I'm sure you block those? We strip macros. Vendors don't like it? Find another one.
-
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
That's way different. Internal use vs sending them out. Sending them out is just as bad or worse than sending an .exe or .bat etc? I'm sure you block those? We strip macros. Vendors don't like it? Find another one.
To the best of my knowledge I can't strip macros with AppRiver - but I'll check into it tomorrow to be sure. They can block by extension - which I've done in the past... but doesn't help here.
-
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
That's way different. Internal use vs sending them out. Sending them out is just as bad or worse than sending an .exe or .bat etc? I'm sure you block those? We strip macros. Vendors don't like it? Find another one.
To the best of my knowledge I can't strip macros with AppRiver - but I'll check into it tomorrow to be sure. They can block by extension - which I've done in the past... but doesn't help here.
Weird if it can't. Ours can strip them or print them to PDF and replace them
-
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
That's way different. Internal use vs sending them out. Sending them out is just as bad or worse than sending an .exe or .bat etc? I'm sure you block those? We strip macros. Vendors don't like it? Find another one.
To the best of my knowledge I can't strip macros with AppRiver - but I'll check into it tomorrow to be sure. They can block by extension - which I've done in the past... but doesn't help here.
Weird if it can't. Ours can strip them or print them to PDF and replace them
A macro?
-
You can block macros in Word, but leave them in Excel. Most ransomware comes as an infected Word document rather than an Excel document doesn't it? This is what I do.
You can also allow macros to run in protected locations eg your intranet/fileserver. So if the user wants to run a macro in external file, they would simply need to save a copy on their intranet/fileserver and then open it from there (I think).
-
@Carnival-Boy said:
You can also allow macros to run in protected locations eg your intranet/fileserver. So if the user wants to run a macro in external file, they would simply need to save a copy on their intranet/fileserver and then open it from there (I think).
That's not blocking them though, a user could save the malicious file to the fileserver and then it would run the malicious code.
-
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
@Dashrender said:
@Jason said:
How are those Doc Files getting in anyway? does your solution not include a cloud spam/email filter to pull out things like that?
Pull out things like what? Zeroday exploits?
Files that have macro's in them. No reason those would be emailed from the outside.
Well I'll take you back to your own post
@Jason said:
Good luck with that. Many people write their own macro's in excel to help with their jobs.
I've had vendors send me quotes using their own sheets that contain macros they use to gather data before - sure it's rare, but it happens.
That's way different. Internal use vs sending them out. Sending them out is just as bad or worse than sending an .exe or .bat etc? I'm sure you block those? We strip macros. Vendors don't like it? Find another one.
To the best of my knowledge I can't strip macros with AppRiver - but I'll check into it tomorrow to be sure. They can block by extension - which I've done in the past... but doesn't help here.
Weird if it can't. Ours can strip them or print them to PDF and replace them
A macro?
It can be set to strip the macro's out or Print the whole file to a PDF. The PDF would not have macro's. Our solution even will scan for urls in documents and see what they are.
-
@Jason said:
It can be set to strip the macro's out or Print the whole file to a PDF. The PDF would not have macro's. Our solution even will scan for urls in documents and see what they are.
what are you using?
