WOLF & CO Insights Malicious PowerShell Attacks – Why They Will Soon be the Least of Your Problems

Malicious PowerShell Attacks – Why They Will Soon be the Least of Your Problems

Written by: Joseph Sarkisian, GWAPT

Introduction to SilentTrinity

Over the past year, Marcello Salvati (@byt3bl33d3r) of Black Hills InfoSec has been quietly working on a tool that is likely to become a paradigm shift for hacking—white and black hat alike. When attacking Windows environments, Windows PowerShell has been the tool of choice, but Microsoft has become hip to this tactic and has added significant protections that help mitigate the use of malicious PowerShell scripts from running. What we now have is a cat-and-mouse game where hackers find ever-more-creative ways of bypassing these controls, only to have Microsoft and other “blue team” types fill the gap.

That game is about to end.

In Marcello’s words:

SILENTTRINITY is a modern, asynchronous, multiplayer and multiserver C2/post-exploitation framework powered by Python 3 and .NETs DLR. It’s the culmination of an extensive amount of research into using embedded third-party .NET scripting languages to dynamically call .NET API’s, a technique the author coined as BYOI (Bring Your Own Interpreter). The aim of this tool and the BYOI concept is to shift the paradigm back to PowerShell-style-like attacks (as it offers much more flexibility over traditional C# tradecraft) only without using PowerShell in any way.”

What this really means is that the tool allows hackers to bypass the use of PowerShell, thus going largely undetected—especially given that Microsoft has focused the majority of its protections and alerting on PowerShell, not the lesser known .NET languages (like BooLang) that SilentTrinity utilizes.

The tool allows multiple users to log in to a central server where compromised machines can be manipulated. Once a server is started (called a “listener”), the hacker generates malicious code (a “stager”), and the victim runs the malicious code, thereby opening a session (“hacking” session) on the attacker’s SilentTrinity server. From there, many different modules can be run against the victim host that include things like information gathering and enumeration, privilege escalation, disabling endpoint protection, creating persistence, dumping credentials, changing/downloading registry keys, and more. All of these modules, such as IronPython and Python, are written in BooLang, which has few, if any, protections when run.

How it Works

The following examples will demonstrate how a hacker could use SilentTrinity to attack your system.

In the image below, we have started an http listener on our attacking host at port 80 and named the listener “http:”

Next, we generate a stager that, when executed, will call back to this listener. Let’s use an MSBuild stager that we can execute on a victim host using the Microsoft .NET compiler:

Once this stager is dropped on a host machine, we can compile it with msbuild.exe from the command prompt, PowerShell or a similar program. For simplicity, let’s use a PowerShell script example to run msbuild.exe on the stager.xml file we have placed on the disk. Notice that we aren’t executing malicious PowerShell scripts or executables, only a known, verified Microsoft application:

And on our attacking host, our new session:

Now we’re ready to use some modules to further compromise our victim machine, all of which are likely to go unnoticed given their usage of BooLang. Let’s try a fun one first—pop-up box. First, we set our text for the box:

And on our victim machine, voilà…

Now, let’s get scarier. Let’s phish for some plaintext credentials using the CredPhisher module. After executing, we can see a pop-up box appear on the victim host that looks convincing asking for our Windows credentials:

Once we provide credentials, here’s what we get on our attacking SilentTrinity server:

Finally, let’s privilege escalate to SYSTEM using the “getsystem” module:


As of now, there are very few mitigations to deal with this threat, and that will likely become the new normal for hackers everywhere as PowerShell security becomes increasingly robust. A few options are:

• Process monitoring for a BooLang interpreter

• Advanced host/network monitoring for suspicious C2 traffic originating from MSBuild

• Updating to .NET 4.8 as soon as possible because it integrates with Microsoft’s Antimalware Scan Interface (AMSI)