Eset researchers recently revealed some rather sophisticated fileless malware samples that cyber criminals use. Fileless malware is malicious software that only runs directly in computer memory, making it more difficult for traditional malware products to detect. The WatchGuard Threat Lab predicted a general rise of fileless malware during 2019, but more specifically forecasted that you would see fileless malware incorporate automatic network spreading techniques to create a new threat we call a vaporworm. We believe this prediction came true early.
This post delves into Eset’s research and the foul usage of Windows’ PowerShell scripting language, which attackers often use for fileless malware. Turla, the attackers in this case, are a force to be reckoned with. They have a very notable line up of victims as highlighted in their post. I’m going to break down how these attack works.
How These Attacks Work
Previously, researchers from Kaspersky have seen the Turla group use PowerShell loaders based on an open-source project called Posh-SecMod. The Turla group updated the scripts to include three main characteristics; maintaining persistence, decryption, and loading embedded executables or libraries into memory. Let’s cover each category a bit more to see how these different stages unfold, then focus on some takeaways from each phase.
Persistence
The updated scripts can leverage two PowerShell methods to maintain persistence:
- Subscribing to Windows Management Instrumentation (WMI) events
WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is a technology used in enterprise environments for accessing management information. Simply put, WBEM makes it easier for you to remotely manage many computers by standardizing how system management information is retrieved.
- Altering the PowerShell profile file
PowerShell is an interactive command-line shell offering flexibility to system administrators. Administrators are able to rapidly automate operating systems management tasks. PowerShell profiles are customizable environments that allow user-specific configurations. This allows for multiple system administrators to tweak settings differently without conflicting with each other’s PowerShell profiles.
Delving into the WMI method.
Let’s expand on the above introduction into WMI. It uses events that are made available by what are known as event providers. Events are data or services on a computer that produce notifications. Event providers are abstract layers that interface WMI and a managed object. If you’d like, you can even customize what data is provided to WMI. Examples of events include services have stopped working, a data storage pool’s threshold is reaching full capacity, and generated security logs.
The way you collect the data that event providers make available to WMI is via clients, referring to the method of how you access said data. Using PowerShell is one way, there are other languages available and you can learn more about how to create WMI clients here.
Four total event subscriptions are created, two event filters and two event consumers. Event filters basically dictate which events WMI should send to a consumer. Therefore, event consumers detail how to act upon that event.
The two filters run at specific times; one about five to seven minutes after a system boots and the other at 3:30:40 PM. These filters initiate the consumers’ PowerShell commands. The base64-encoded commands contain where in the Windows registry another encrypted PowerShell script resides, and the password and salt needed to decrypt that registry entry. The Turla group uses the base64 encoding and encryption to help the scripts evade detection by local security controls. The consumers also store the results of these PowerShell commands back into the Windows registry.
Before leaving this subsection, I want to highlight that there are many benefits to this feature if it’s not already clear – for both administrators as well as threat actors. That said, ensuring it is securely set up is imperative considering the gravity of the threat landscape. For additional reading, this article dives more into WMI’s intricacies and here you can read Microsoft’s documentation for securing remote WMI connections. To learn more about how attackers can use WMI for nefarious purposes, refer to Matt Graebar’s 2015 Black Hat publication and this other post, which summarizes investigating WMI attacks.
Looking at the PowerShell profile method.
The profile method is similar in concept. In this case, the attackers hijack the PowerShell profile file and embed a base64-encoded command within it. That PowerShell script does the same thing as above. When PowerShell initializes, it carries out the profile and thus executes the malicious stored script. Again, these malicious scripts grab and store things in various registry entries.
The takeaway here is for administrators to periodically review their configuration profile for anything suspicious. In fact, a huge red flag is if an administrator has a PowerShell profile despite not having knowingly created one! My recommendation is to create a backup of a known and clean version and store it offline, then compare the two from time to time. Should administrators choose to edit their profile in the future, create another offline backup for comparison. The second hyperlink introducing PowerShell explains more about this profile, and you can refer to this on how to customize one.
As for additional material, there are many studies in exploiting PowerShell profiles. Here is a shorter post that describes how to abuse these profiles; it’s a proof-of-concept that eventually runs the Calculator program silently in the background, and this post lists attack techniques using PowerShell. And of course, Ryan Kazanciyan and Matt Hastings presented Investigating PowerShell Attacks at Black Hat USA 2014.
In short, with two built-in Windows mechanisms and the ability to store encrypted data in the registry, these PowerShell scripts can allow fileless malware to regain persistence.
That said, seeing that the registry is common in either scenario, knowing what and how the Windows registry works is useful. Per Microsoft’s documentation, registry “…is a system-defined database in which applications and system components store and retrieve configuration data.” This resource highlights the registry’s hierarchy as well as how to use the corresponding editor, or you can refer to Microsoft’s documentation on its hierarchy here or for more advanced users, refer to this one.
After getting a basic understanding of the registry, knowing what to look for is next. Use this CSO article to get started, and this one to extend the thought process behind investigations. Take a backup from time to time, similar to the PowerShell profile approach, and compare the two for changes. Anything unknown to administrators should stand out. For more in-depth reading, see FireEye’s extensive coverage into registry forensics.
Decryption
The secondary PowerShell payload script stored in the Windows registry is from an open-source penetration testing framework, PowerSploit. The payload is encrypted using 3DES. Encrypting the payload helps avoid detection due to the nature of how encrypted content is stored, thus benefiting the attacker. Storing content in plaintext allows antivirus mechanisms the ability to scan said content. Encrypting the content impairs this, however, making it harder to detect.
WatchGuard’s own Corey Nachreiner wrote a two-part series on how malware authors are hiding malware on computer systems. Read the first part here on Dark Reading as this one specifically covers malware using encryption.
The decrypted payload reveals a tool that loads itself into the memory of another randomly chosen process currently running on the system. This feature is available within PowerSploit as well. Some examples had additional logic to prevent injection into Kaspersky executables. This tactic is used to prevent the tampering of data associated with the products of anti-malware vendors. Many companies, such as Kaspersky, have malware analysts on the lookout for such actions.
Restricting Anti-malware Scan Interface (AMSI).
Some modifications even allow bypassing the AMSI security feature. AMSI is an interface that allows applications and services to integrate with any anti-malware product installed on a host computer. The script did this using a technique presented at Black Hat Asia 2018. This feature essentially allows the PowerShell script to always return a “AMSI_RESULT_NOT_DETECTED” flag to the service. This basically prevents anything from being scanned. With no ability to scan anything, this service is rendered useless.
Payloads
The Turla group uses a few different payloads. I’ll expand on the ones listed in the research article:
- This payload sets up a Remote Procedure Call (RPC) server. RPC is a protocol that simply allows a client to request a server to do something. Some features include uploading and downloading files, executing commands, as well as accepting various plugins extending the feature set. More grave features include token shenanigans. Tokens are basically a process or thread’s security context and is what allows or denies access to certain resources based on privileges.
One method entails trying to use a system’s ImpersonateAnonymousToken function, which allows anonymous access if the system allows it. The other is an attempt to hijack a different process token for the execution of a nefarious command, which allows said command to be seen in the context of the hijacked process. This is a form of masking activities by using the front of another legitimate process. Check out the original post for more technical detail about how this is done.
Takeaways here include ensuring anonymous functions cannot be executed (disabled by default) as well as expanding your knowledge of process tokens. As for known attack methods, refer to this link.
- A similar tactic as above but utilizing an RPC Spoof Server, this method attempts to hijack an already registered RPC interface. An RPC interface is akin to any server accepting and awaiting incoming IP communication requests.
This approach sifts through a process list’s usage of specific ports or pipes, a form of inter-process communications allowing multiple processes to work together. Once obtained, the data is perniciously altered while in computer memory to suite Turla’s needs. In-memory adjustments increase concealment, much like hijacking a different process token, but this time it’s in the context of RPC communications.
Again, for both methods, the post has additional technical detail.
- Another alternative consists of “PowerStallion,” a PowerShell-based backdoor leveraging Microsoft’s OneDrive Cloud storage service as a command and control channel. Previously siphoned credentials are hardcoded in the script with actual names of employees and used for authentication purposes. PowerStallion is able to connect to network drives, check for available uploaded commands to run locally (only PowerShell scripts are permitted, based on the article), it then writes the results back into a separate subfolder within OneDrive and is encrypted with the XOR key “0xAA.”
Another interesting find about this payload is that it changes modification, access and creation timestamps. That is, files have timestamps matching when it was last modified, accessed, or when it was initially created; this script alters these timestamps of log files to match another legitimate file on that computer – in this example of the desktop.ini file. This is a form of masking activities by altering access times. Eset researchers suspect PowerStallion to be a failsafe should something happen preventing further access by Turla. It can also be used as a hidden method of monitoring various aspects; anti-malware logs, running processes, etc.
Conclusion
After reading more about this PowerShell attack, it’s clear to me that legitimate pen-testing tools, though created by good guys to help the security community, can be exploited maliciously too. Most, if not all, open-source software is made available to help the community. Unfortunately, the community includes the bad guys as well. That said, it’s imperative that system and network admins are aware of these threats and what’s openly available online.
To harden your network, I strongly advise periodic pen-tests on your own network using similarly available tools or use an entity that specializes in doing this. Other options include regular analysis of network logs, though this requires more technical skill. Consider how a Window OS interfaces with other Cloud-based Microsoft services, such as automatic backups to OneDrive. PowerStallion exploits the traffic flow by masking itself in like-traffic. Differentiating the foul traffic from legitimate backup data isn’t straightforward. In fact, the tactic of using hosting providers as a front has become more prominent for threat actors instead of hardcoding IP addresses.
I also mentioned suggestions throughout the post, but I’ll summarize and expand a bit more here. System admins could periodically review their PowerShell configuration profile(s). Tying in how altering MAC times can mask activities, if an admin’s profile was recently modified, a more recent timestamp should raise a flag of concern especially if that admin didn’t recall any modifications. However, if an attacker would save the current timestamp or copy another file’s timestamp, the altered timestamp could throw off an unsuspecting admin. Manually reviewing the file is best, you could even compare a backup copy that hasn’t been accessible over the network with the current one using a program that detects differences.
There is no catch-all tactic, however, as determined threat actors continuously try to subvert current security processes. The best thing to do is a multi-faceted approach by employing the above but extending that to host-based hardening. You can read more enlightening insight here. Lastly, the registry is a key in fileless malware in general. Periodically compare registries to ensure no unknown actions have been taken upon it.