THREAD
Let's analyze a malicious VBA macro payload. On visual inspection, we can easily see that the macro performs string concatenation and then uses Shell() to execute a PowerShell script. It declares AutoOpen() & Workbook_Open() in order to execute when the document is opened.
Let's analyze a malicious VBA macro payload. On visual inspection, we can easily see that the macro performs string concatenation and then uses Shell() to execute a PowerShell script. It declares AutoOpen() & Workbook_Open() in order to execute when the document is opened.
Once we decode the base64 script from the macro, we can see that it further obfuscates its intention with more base64 encoding and gzip compression.
When we decode & decompress the long string, we get the final PowerShell payload. This script creates a byte array containing shellcode from another base64 encoded string, which it will then reflectively load into kernel32.dll running in memory.
When we load the shellcode in a debugger, we can see that it calls user32.dll!MessageBox to display the message "Hello, from MSF!" which is the default message from this Metasploit payload module: github.com/rapid7/metaspl…
From a detection perspective, the process parent/child hierarchy here would have been a dead giveaway:
Excel.exe
↪️powershell.exe
↪️C:\WINDOWS\syswow64\WindowsPowerShell\v1.0\powershell.exe
Sysmon EventID:1 logs, folks. No excuses.
Excel.exe
↪️powershell.exe
↪️C:\WINDOWS\syswow64\WindowsPowerShell\v1.0\powershell.exe
Sysmon EventID:1 logs, folks. No excuses.
At first you might write this off as Red Team / pentest tactics, but if you replace the pop-up message payload with one of the Metasploit stager payloads, you're looking at an exact set of TTPs used on-and-off by TA505 over the past several years to drop Dridex and other trojans.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
