As per Mitre ATT&CK, ID S0154 tracks Cobalt Strike as a “commercial, full-featured, remote access tool that bills itself as “adversary simulation software” designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”.
Cobalt Strike has gained notoriety in the world of cyber breaches as a highly effective and widely used tool by threat actors and hackers. It’s often associated with advanced persistent threat (APT) groups and sophisticated cyberattacks.
In this write-up we’ll be taking a look at .HTA files which are frequently used to get an initial access into a network. And then using Cobalt Strike we create a listener and embed our beacon payload into the HTA to get it executed.
Note — All actions detailed in this article are carried out within a virtualized environment.
So, what is an HTA file?
HTA short for HTML Application files is a Microsoft Windows program whose source code consists of HTML, Dynamic HTML, and one or more scripting languages supported by Internet Explorer, such as VBScript or JScript. An HTA executes without the constraints of the browser’s security model, so it executes as a “fully trusted” application.
In Microsoft Windows HTA is executed using
mshta.exe which is typically installed along with Internet Explorer. In fact,
mshta.exe is dependent on IE, so if it has been uninstalled, HTA will be unable to execute. So let’s see what a basic HTA code looks like and the after effects of it getting executed.
<title>This is a HTA!</title>
Save the above HTML with the file extension as .hta and then run the file.
Now let’s add some VBScript that will execute something on the user’s machine. So let’s launch calc.exe using .HTA file on our VM machine.
<head><title>This is a HTA!</title></head>
Set shell = CreateObject("wscript.Shell")
In the above code we have added VBScript, where we created a function RunCalc which is responsible for running ‘calc.exe’. The
wscript.Shell object provides access to the Windows shell methods and the
run method simply allows us to run an application from disk. Running the above .hta will result in calc.exe being executed.
So we now have the basics of HTA and how we can execute something on a machine using VBScript.
Let’s move to Cobalt Strike and make a listener and instead of running calc.exe we add our beacon payload in the HTA so that when we run it’ll trigger our payload and resulting in compromising the machine.
A listener is the component that waits for an incoming connection from an exploited system. So, we create a basic HTTP listener here which will listen on port 80 for any incoming connections from the Victim VM.
After saving the listener, we create our powershell payload using “Scripted Web Delivery (S)”. This feature generates a stageless beacon payload artifact, hosts it on Cobalt Strike’s web server, and presents a one-liner to download and run the artifact. So let’s do that…
You can change the URI path to anything but we’ll keep it as the default. Local Host is the attacker IP which CS automatically fills in along with the port we’ll use. After choosing our listener which we created in the previous step we check the x64 box as we want a 64bit payload. Click on launch & we get our one-liner.
It should be noted here that attackers tend to obfuscate this one-liner by encoding with base64, performing compression and by using various other obfuscation methods in order to evade detection.
Now we’ll be using this one-liner in our HTA file so that when the ‘victim’ executes the HTA this powershell code gets executed which will then fetch our payload hosted on our Cobalt Strike webserver and then run it on the victim’s machine. So let’s see it in action…
So this is what our HTA looks like after making the necessary changes.
Please note here that I’ve explicitly used C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe as we are using x64 payload and we want
mshtato be launching the 64-bit version of PowerShell instead of the 32-bit one.
During the execution you can see the powershell window popping up which means our payload got executed. Taking a look into our CS client we can see a connection.
We can interact with the beacon and try to issue some shell commands to see if it works. Default sleep time for a beacon is 60 seconds which means every 60 seconds the beacon will call “home” (C2 server) to get the issued tasks. This can be changed by issuing a ‘sleep’ command.
sleep 5 // This will set the sleep time to 5 seconds meaning beacon will call home every 5 seconds.
As you can see above we issue shell commands like whoami, hostname and got the results. If you see above the command window the sleep is set to 5 seconds and the value of the field ‘last’ is a counter that counts till 5 after which we get contacted by the beacon (“host called home” in command line).
This write-up was aimed more at a basic level of usage which means there are plenty on things that real-world adversaries will do and have done differently. They’ll go on to lengths to evade detection by obfuscating their payloads and workings of their beacon in order to blend in with the legitimate activity on the victim’s machine.
Recently Microsoft announced that they’ll be retiring VBScript in Windows as an attempt to reduce the cases of malware delivery. But adversaries always come up with new ways of exploitation. That’ll be it for this write-up. I hope you enjoyed it.
Thanks for reading!
Good Reads —