PowerShell Shellcode Runner
Although we have a working exploit, there’s room for improvement.
First, the document contains the embedded first-stage Meterpreter shellcode
and is saved to the harddrive where it may be detected by antivirus.
Second, the VBA version of our attack executed the shellcode
directly in memory of the Word process.
If the victim closes Word, we’ll lose our shell.
In this section, we’ll change tactics a bit.
First, we’ll instruct the macro to download a PowerShell script,
which contains our staging shellcode, from our web server and run it in memory.
This is an improvement over our previous version
that embedded the shellcode in the macro within the malicious document.
Next, we’ll launch the Powershell script as a child process of,
and from, Microsoft Word.
Under a default configuration, the child process will not die
when Microsoft Word is closed, which will keep our shell alive.
To accomplish this, we’ll use the DownloadString method
of the WebClient class to download the PowerShell script directly into memory
and execute it with the Invoke-Expression commandlet.
We can reuse the exact same Windows APIs to execute the shellcode.
However, we must translate the syntax from VBA to PowerShell.
This means we must spend some time discussing the basics
of calling Win32 APIs from PowerShell.