The Adventures of the Elusive Malvari, Part I

With this article, we begin a series of publications about elusive malvari. Hacking programs that leave no traces of attack, also known as fileless, typically use PowerShell on Windows systems to covertly execute commands to find and extract valuable content. Detecting hacker activity without malicious files is a difficult task, because antiviruses and many other detection systems work based on signature analysis. But the good news is that such software does exist. For example, UBA systems that can detect malicious activity in file systems.

When I first began to study the topic of cool hackers who do not use traditional methods of infectionand only the tools and software available on the victim’s computer, I did not suspect that this would soon become a popular attack method. Security professionals say this is becoming a trend, and frightening article titles are proof of that. Therefore, I decided to make a series of publications on this topic.

Great and terrible PowerShell

I wrote about some of these ideas earlier in the PowerShell obfuscation series , but more in theory. Later I came across a site for hybrid analysis , where you can find samples of malvari, "caught" in the wild. I decided to try using this site to search for fileless malware samples. And I did it. By the way, if you want to go on your own expedition to search for malware, you will have to go through a check on this site so that they know that you are doing the work as a white hat specialist. As a blogger who writes about security, I went through it without question. I'm sure you can too.

In addition to the samples themselves, you can see on the site what these programs do. Hybrid analysis launches malware in its own sandbox and tracks system calls, running processes and actions on the network, and also extracts suspicious text strings. For binary files and other executables, i.e. Where you cannot even look at the actual high-level code, hybrid analysis decides whether the software is malicious or simply suspicious based on its activity at runtime. And after that the sample is already evaluated.

In the case of PowerShell and other sample scripts (Visual Basic, JavaScript, etc.), I was able to see the code itself. For example, I came across such a PowerShell instance:

You can also run base64-encoded PowerShell to avoid detection. Pay attention to the use of Noninteractive and Hidden parameters.

If you read my obfuscation entries, then you know that the -e option indicates that the content is encoded in base64. By the way, hybrid analysis also helps with this, decoding everything back. If you want to try to decode base64 PowerShell (hereinafter - PS) yourself, you need to run this command:

 [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))

Go deeper

I decoded our PS-script using this method, the text of the program is presented below, although slightly modified by me:

Note that the creak was bound to the date September 4, 2017 and passed session cookies.

I wrote about this attack style in the PS obfuscation series , in which the base64 encoded script itself downloads the missing malware from another site, using the WebClient object from the .Net Framework library to do all the hard work.

What is it for?

For security software that scans Windows event logs or firewalls, base64 encoding prevents the detection of the WebClient string by a simple text pattern to protect against such a web request. And since all the "evil" malware is then downloaded and transferred to our PowerShell, this approach thus allows you to completely avoid detection. Rather, I thought so at first.

It turns out that with the inclusion of advanced logging of Windows PowerShell logs (see my article), you can see the loaded line in the event log. I (like others ) believe that Microsoft should enable this level of logging by default. Therefore, when extended logging is turned on, we will see in the Windows event log a completed request to load from a PS script according to the example that we examined above. Therefore, it makes sense to activate it, agree?

Add additional scripts

Hackers deftly hide a PowerShell attack in Microsoft Office macros written in Visual Basic and other scripting languages. The idea is that the victim receives a message, for example, from a delivery service, with an attached report in .doc format. You open this document, which contains a macro, and ultimately it launches the malicious PowerShell itself.

Often, the Visual Basic script itself is obfuscated so that it freely evades antiviruses and other malware scanners. In the spirit of the above, I decided as an exercise to encode the above PowerShell in JavaScript. Below are the results of my work:

Obfuscated JavaScript hiding our PowerShell. Real hackers do it once or twice.

This is another of the techniques I've come across on the net: using Wscript.Shell to run encoded PowerShell. By the way, JavaScript itself is a means of delivering malware. Many versions of Windows have a built-in Windows Script Host , which itself can run JS.
In our case, the malicious JS script is attached as a file with the .doc.js extension. Windows typically only shows the first suffix, so it will appear to the victim as a Word document.

The JS icon is displayed only in the scroll icon. It is not surprising that many people will open this attachment, thinking it is a Word document.

In my example, I modified the PowerShell above to download the script from my website. The remote PS script simply prints Evil Malware. As you can see, he is not at all evil. Of course, real hackers are interested in gaining access to a laptop or server, say, through a command shell. In the next article I will show how to do this using PowerShell Empire.

I hope that for the first introductory article we did not dive too deeply into the topic. Now I’ll let you take a breath, and next time we will begin to analyze real-life examples of attacks using fileless-malvari without extra introductory words and preparation.