Reply to thread

Message

<blockquote data-quote="Andy Ful" data-source="post: 931001" data-attributes="member: 32260">Microsoft added AMSI protection for VBA macros (MS Office 365) so the attackers changed the attack vector to Excel 4.0 macros. They are used to download and invoke more persistent payloads, such as EXE or DLL files.So, this new vector can be prevented by using Windows build-in features:<ol>
<li data-xf-list-type="ol">Blocking child processes of Excel and restricting WMI to avoid bypassing child processes checking (ASR rules)</li>
<li data-xf-list-type="ol">Restricting scripting (SRP, Applocker, Application Control)</li>
<li data-xf-list-type="ol">Blocking scripts via Windows Policies.</li>
</ol>Many AVs have still problems with mitigating Excel 4.0 macros.&quot;Security vendors are having difficulty detecting this threat, likely due to not having solutions in place to properly assess and parse the format and structure of how these macros are stored in Excel documents [2]. These macros are very straightforward and easy to create, thus easy to modify to bypass signature-based detection. Macros are also robust, and provide various functions that can be leveraged to evade analysis, such as obfuscating the final payload, modifying the control flow, or detecting automated sandbox analysis through specific host environmental checks.&quot;[URL unfurl=&quot;true&quot;]https://www.lastline.com/labsblog/evolution-of-excel-4-0-macro-weaponization/[/URL]Edit.Excel 4.0 macros can also use Windows APIs to filelessly execute the shellcode without using external scripting engines like PowerShell (rarely used in the wild). In the case of VBA macros, this could be prevented by the ASR rule &quot;Block Win32 API calls from Office macros&quot;. But, this rule most probably will not work for Excel 4.0 macros except when Microsoft will update it to cover them.</blockquote>

[QUOTE="Andy Ful, post: 931001, member: 32260"] Microsoft added AMSI protection for VBA macros (MS Office 365) so the attackers changed the attack vector to Excel 4.0 macros. They are used to download and invoke more persistent payloads, such as EXE or DLL files. So, this new vector can be prevented by using Windows build-in features: [LIST=1] [*]Blocking child processes of Excel and restricting WMI to avoid bypassing child processes checking (ASR rules) [*]Restricting scripting (SRP, Applocker, Application Control) [*]Blocking scripts via Windows Policies. [/LIST] Many AVs have still problems with mitigating Excel 4.0 macros. "[I]Security vendors are having difficulty detecting this threat, likely due to not having solutions in place to properly assess and parse the format and structure of how these macros are stored in Excel documents [2]. These macros are very straightforward and easy to create, thus easy to modify to bypass signature-based detection. Macros are also robust, and provide various functions that can be leveraged to evade analysis, such as obfuscating the final payload, modifying the control flow, or detecting automated sandbox analysis through specific host environmental checks[/I]." [URL unfurl="true"]https://www.lastline.com/labsblog/evolution-of-excel-4-0-macro-weaponization/[/URL] Edit. Excel 4.0 macros can also use Windows APIs to filelessly execute the shellcode without using external scripting engines like PowerShell (rarely used in the wild). In the case of VBA macros, this could be prevented by the ASR rule "Block Win32 API calls from Office macros". But, this rule most probably will not work for Excel 4.0 macros except when Microsoft will update it to cover them. [/QUOTE]

Verification