Weaponizing Microsoft Word: Hacking a Windows 10 Machine

This post will teach you how to hack a Windows 10 Pro machine with Metasploit and Kali Linux. It will go into considerable depth regarding what some of the Metasploit modules do, some of the challenges I faced during exploitation, and how I was able to resolve them and establish root level persistence on the target machine.

The attack I was trying to construct had to meet certain parameters:

1. Target a Windows 10 System
2. Remote delivery (cannot simply double click a payload from the Desktop)
3. Exploit a vulnerability within an Office application or system process
4. Achieve remote code execution on the victim machine
5. Achieve privilege escalation on the victim machine
6. Establish persistence on the victim machine
7. Explain the risk that this attack represents and challenges that IT organizations face in protecting against it
8. Sell a potential solution

Targeting an Office application was appealing because it would be easy to put into context (important for requirements 7 and 8). One can easily imagine a scenario where a threat actor targets a company employee with a Word document attached in an email. The subject line could be something tricky like: “Quarterly Feedback”, “New Company Covid-19 Policy”, or “Extended Vacation Policy”.

I began the reconnaissance stage by searching for reliable Metasploit modules that targeted relatively recent versions of Microsoft Word.

Module number five jumped out at me as it was the second most recent module and had an “Excellent” ranking.

The “Microsoft Office Word Malicious Hta Execution” vulnerability was first observed in the wild on April 6, 2017 by security researchers at McAfee (mcafee.com). The vulnerability allows a threat actor to “download and execute a Visual Basic script containing PowerShell commands when a user opens a document containing an embedded exploit”, (fireeye.com).

More precisely, here’s a breakdown of how the exploit takes place:

1. The target user opens the Word or RTF file containing the embedded OLE2 object
2. When the user opens the document or clicks on the object (depends how the exploit is configured), winword.exe makes an HTTP request to a remote server to retrieve a malicious .HTA file
3. The .HTA file returned contains an embedded malicious script
4. The winword.exe process looks up the file handler for the .HTA application which causes the “Microsoft HTA application (Mshta.exe) to load and execute the malicious script

These PowerShell commands provide the threat actor with a reverse shell which he can then leverage to download and execute malware payloads onto the victim machine. LatentBot and Dridex malware were observed (fireeye.com).

We can exploit this vulnerability with the following Metasploit module: exploit/windows/fileformat/office_word_hta

Running this module will present us with a URL that represents the HTTP request that gets made when the user opens the malicious Word document. This module basically represents a phishing style attack.

If we visit this URL on our victim machine the malicious “.hta” file gets downloaded. When we open the file the VBS script runs and we gain a reverse shell and initial access.

Malicious .hta file gets downloaded on our machine

Technically, what we have is a reverse meterpreter session and not a shell. A meterpreter session is like a shell except it allows you to run Metasploit modules on the victim machine. By default, Metasploit will try to upload a meterpreter session. If for some reason it’s unable to, it will provide a standard command shell (docs.rapid7.com).

We can then drop into our meterpreter session and run standard meterpreter commands to gather system info and try to take control:

Two things worth noting: first, we have an x86 meterpreter session on a x64 Windows machine, and second, the “getsystem” command is not working. The mismatch in architecture has the potential to cause issues when using certain modules later in the exploit. The getsystem command is not working because while our user is in the Administers group, they do not have all the same permissions as the built in Administrator account (rydel.com). We still need to find a way to bypass User Account Control (UAC).

The exploit/windows/local/bypassuac_fodhelper module will help us achieve this by abusing the permissions elevation control mechanism. The fodhelper.exe process is the executable used by Windows to manage features in Windows settings. This Metasploit module hijacks the fodhelper registry key and inserts a custom command that will be launched when the fodhelper.exe application is run. This command will spawn a second shell which has the User Account Control (UAC) flag disabled (hackingarticles.in).

Let’s attach our user session to the module, provide our module with an open port for the reverse shell, and run the exploit:

Now when we use the getsystem command, we succeed in taking control of the system. The next step is establishing root level persistence.

One way we can do this is by creating or modifying a system process. By sending a persistent service to the victim machine, whenever the victim power cycles their machine, the service will restart and we’ll regain our reverse shell.

The exploit/windows/local/persistence_service module uploads an executable onto the victims machine and makes it a persistent service. When the service runs, it initiates a TCP connection and provides us with our reverse shell. For it to work, the module has to be run on a session that already has root level persistence. Let’s attach the module to our root level session, provide it with an open port, and run the exploit:

The vRBFQWnR.exe has been successfully loaded onto the victim machine

We can flip over to our Windows machine and verify that this service is now running:

In order to regain a reverse shell when the victim machine power cycles we can leverage the multi-handler module multi/handler and provide it with the “windows/meterpreter/reverse_tcp” payload. This module is a stub that will run what ever payload handler we specify (rapid7.com). In our case, we just need something that will listen on the port that our persistent service will try to call back to.

Let’s go ahead and power cycle the system and see if we succeed in generating reverse shell.

All of our previous sessions die out. However, once the persistent service restarts on the victim machine it initiates a connection to port 4446 on the attacking machine (us). Our multi-handler will pickup this connection and provide us with a root shell once again.

Hopefully, your understanding of a cyber attack kill chain and how to use Metasploit improved. In the next tutorial, we’ll demonstrate how we can infect this now compromised system with malware. Onwards and upwards!