March 24 2022 Thursday
Ransomware Prevention Part 9 - More semi-easy stuff
Part 9 - More semi-easy stuff
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
Well, it's been a while since part 8, but this series generated a lot of work for STS, so I'm not complaining. After doing some of this stuff for a while now I have some more suggestions for you to implement.....
HTA - the malware distribution engine Microsoft provides free of charge
I always forget organizations still have and use Internet Explorer. Thanks Microsoft! Even though it goes end of life in June 2022, it's still used in a lot of places. A lot. Not only did MS foist IE on us, but they also bundled on top a thing called HTML Application (HTA for short, see https://en.wikipedia.org/wiki/HTML_Application). And this thing keeps giving, and giving, and giving. In short it allows a bad actor to trick your users into possibly opening a bad application. See HTAs don't use the security model of the browser. No, HTA's are fully trusted applications that use the IE engine and allows VBScript and JScript to run with access to the file system and the registry. Without supervision. FYI, file system access is how ransomware encrypts shared drives, You've just connected the dots right? From the Wikipedia article above:
Then this gem....
Holy $%*# Batman.
In all my years doing this I don't recall seeing a single practical use for HTAs. The only time I've seen it used is to distribute malware via a script based attack. To block this super villain sized nastiness do as many of these things as you can:
1. Block all .HTA files from running. Period. Use a software restriction policy, add it to your endpoint protection. Add it everywhere.
2. Block mshta.exe from running. Again, use a software restriction policy, add it to your endpoint protection. Add it everywhere.
3. Block the MIME type application/hta.
4. Block files containing MTA:Application header.
5. Delete the .hta file association in Windows,
Do all of the above as HTAs are slippery little buggers. Oh, and just deleting mshta.exe is probably not sufficient as it can be dropped again using a different name. You really need as many of the above as you can figure out how to implement.
If you thought HTAs were bad.....two words: Velvet. Sweatshop. Read on.....
Somewhat harder....Password protected Office files
Look, I know it's hard. People like to think they are in the know by password protecting Excel files. It feeds their superiority complex. However, what you may not know is that if said password is "VelvetSweatshop" (no quotes) it is exceedingly special in Excel. And not in a good way.
Password protected files in Office are actually also encrypted files in Office (the encryption level is based on the Office version, https://en.wikipedia.org/wiki/Microsoft_Office_password_protection). So by being encrypted, these files essentially bypass any and all scanning by your security systems as the scanners cannot see inside the files to analyze them. Still with me? Because this is about to get very, very interesting....
When a user opens a password protected Excel file, Excel (all by itself) tries to use the password "VelvetSweatshop" to decrypt it. And if that is the password on the file, it does and it happily opens the file. Without any user intervention an Excel file protected and encrypted with the password "VelvetSweatshop" opens. Again, in big text.....
And again.....
Yeah, yeah...the daily thought of "what the eff are Microsoft thinking?" shouts inside your head yet again. Yes Excel has a default password. Kinda like crappy Wifi routers, right? Go try it, it's equal parts insane and, well, insane. It still works as of Excel 2201.
So if you can't scan a password protected Office file and Excel will happily open the file and (drum roll please.....), and lets say for kicks and giggles you also have Office macro support enabled (and you do, everyone does)..... then an unsuspecting user can open an Excel file which has neutered all of your high priced security systems, which then runs code (the Office macro), the bad actor could now have a foot hold in your environment. All because of a default password that exists in Excel.
Oh, and if you think the yellow bar at the top of Excel asking if the user wants to trust the macro, and that said user won't click "absolutely", I have some DarrenCoin to sell you.
Which brings us to....
Somewhat, somewhat harder.....Disable Office Macros from running
I their defence, Microsoft is adding extra security in a few months to Office to prevent internet downloaded Office macros from running. That's a step, but after reading about HTAs and Velvet Sweaters are you going to trust Microsoft?
You simply (ha, not that simple at all actually) need to disable Macro support in each and every Office product that has it. If your business processes are so complicated that they require Office Macro support, simplify your process by firing the idiot who designed it and then disable macro support.
Conclusion
Doing the above will seriously raise your security. You'd be better than most, if not all, of your peers. The older the version of Office you are on, the more vulnerable to these attacks you will be. Just saying.....
And if you want to kick your superiority complex into high gear, go ask your security people about HTA and Velvet Sweaters and when they look at you funny, send them this post. They won't sleep for days.
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said all the way back in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
Well, it's been a while since part 8, but this series generated a lot of work for STS, so I'm not complaining. After doing some of this stuff for a while now I have some more suggestions for you to implement.....
HTA - the malware distribution engine Microsoft provides free of charge
I always forget organizations still have and use Internet Explorer. Thanks Microsoft! Even though it goes end of life in June 2022, it's still used in a lot of places. A lot. Not only did MS foist IE on us, but they also bundled on top a thing called HTML Application (HTA for short, see https://en.wikipedia.org/wiki/HTML_Application). And this thing keeps giving, and giving, and giving. In short it allows a bad actor to trick your users into possibly opening a bad application. See HTAs don't use the security model of the browser. No, HTA's are fully trusted applications that use the IE engine and allows VBScript and JScript to run with access to the file system and the registry. Without supervision. FYI, file system access is how ransomware encrypts shared drives, You've just connected the dots right? From the Wikipedia article above:
When a regular HTML file is executed, the execution is confined to the security model of the web browser. This means it is confined to communicating with the server, manipulating the page's object model (usually to validate forms and/or create interesting visual effects) and reading or writing cookies.
Then this gem....
On the other hand, an HTA runs as a fully trusted application and therefore has more privileges than a normal HTML file; for example, an HTA can create, edit and remove files and registry entries. Although HTAs run in this 'trusted' environment, querying Active Directory can be subject to Internet Explorer Zone logic and associated error messages.
Holy $%*# Batman.
In all my years doing this I don't recall seeing a single practical use for HTAs. The only time I've seen it used is to distribute malware via a script based attack. To block this super villain sized nastiness do as many of these things as you can:
1. Block all .HTA files from running. Period. Use a software restriction policy, add it to your endpoint protection. Add it everywhere.
2. Block mshta.exe from running. Again, use a software restriction policy, add it to your endpoint protection. Add it everywhere.
3. Block the MIME type application/hta.
4. Block files containing MTA:Application header.
5. Delete the .hta file association in Windows,
Do all of the above as HTAs are slippery little buggers. Oh, and just deleting mshta.exe is probably not sufficient as it can be dropped again using a different name. You really need as many of the above as you can figure out how to implement.
If you thought HTAs were bad.....two words: Velvet. Sweatshop. Read on.....
Somewhat harder....Password protected Office files
Look, I know it's hard. People like to think they are in the know by password protecting Excel files. It feeds their superiority complex. However, what you may not know is that if said password is "VelvetSweatshop" (no quotes) it is exceedingly special in Excel. And not in a good way.
Password protected files in Office are actually also encrypted files in Office (the encryption level is based on the Office version, https://en.wikipedia.org/wiki/Microsoft_Office_password_protection). So by being encrypted, these files essentially bypass any and all scanning by your security systems as the scanners cannot see inside the files to analyze them. Still with me? Because this is about to get very, very interesting....
When a user opens a password protected Excel file, Excel (all by itself) tries to use the password "VelvetSweatshop" to decrypt it. And if that is the password on the file, it does and it happily opens the file. Without any user intervention an Excel file protected and encrypted with the password "VelvetSweatshop" opens. Again, in big text.....
Without any user intervention an Excel file protected and encrypted with the password "VelvetSweatshop" opens.
And again.....
Without any user intervention an Excel file protected and encrypted with the password "VelvetSweatshop" opens.
Yeah, yeah...the daily thought of "what the eff are Microsoft thinking?" shouts inside your head yet again. Yes Excel has a default password. Kinda like crappy Wifi routers, right? Go try it, it's equal parts insane and, well, insane. It still works as of Excel 2201.
So if you can't scan a password protected Office file and Excel will happily open the file and (drum roll please.....), and lets say for kicks and giggles you also have Office macro support enabled (and you do, everyone does)..... then an unsuspecting user can open an Excel file which has neutered all of your high priced security systems, which then runs code (the Office macro), the bad actor could now have a foot hold in your environment. All because of a default password that exists in Excel.
Oh, and if you think the yellow bar at the top of Excel asking if the user wants to trust the macro, and that said user won't click "absolutely", I have some DarrenCoin to sell you.
Which brings us to....
Somewhat, somewhat harder.....Disable Office Macros from running
I their defence, Microsoft is adding extra security in a few months to Office to prevent internet downloaded Office macros from running. That's a step, but after reading about HTAs and Velvet Sweaters are you going to trust Microsoft?
You simply (ha, not that simple at all actually) need to disable Macro support in each and every Office product that has it. If your business processes are so complicated that they require Office Macro support, simplify your process by firing the idiot who designed it and then disable macro support.
Conclusion
Doing the above will seriously raise your security. You'd be better than most, if not all, of your peers. The older the version of Office you are on, the more vulnerable to these attacks you will be. Just saying.....
And if you want to kick your superiority complex into high gear, go ask your security people about HTA and Velvet Sweaters and when they look at you funny, send them this post. They won't sleep for days.
