#1 Standard Office Macros Settings
Our employee of the month Peter Lustig receives an e-mail from his supplier SuperSchnell GmbH, who has attached a corrected order in an Excel sheet.
Of course, the Excel sheet was protected with a password, because the data protection regulation strictly prohibits anything else xD
So Mr. Lustig opens his e-mail attachment and sees the following message in his Excel program:
Of course, Mr. Lustig activates the contents, as Mr. Immerböser from SuperSchnell GmbH has already pointed out in the e-mail that this is necessary for password protection. The result then looks like this:
The macro downloaded a file “poc_HanseSecure.exe” from the internet, saved it on the desktop (see links above) and executed it. At this point, the program does nothing more than display a MessageBox. A real attacker would not have displayed the first Powershell window, nor used a message box as a payload. Instead, the latter would have either encrypted all writable files (including those on servers) or secretly installed a backdoor to carry out more perfidious attacks.
There are two main ways to prevent these types of attacks (which account for 85% of the more perfidious phishing attacks…):
If no macros are used in the company, you are very welcome to simply close this gate to hell and deactivate macros as a matter of principle 😉
If only specific user groups need macros (for example sales & marketing, who else xD), you could also think about a GPO that excludes this user group from disabling.
The solution with significantly more effort, but which still allows the use of macros across the board, is macro signing.
Here it is also configured via GPOs that only macros can be executed which have been signed accordingly. An example of how you could sign macros has been summarized by Microsoft in a couple of posts.
*From the blog series Top Security QuickFails