Powershell Empire is a household name for penetration testers, red team members, and even your favorite APT group. Combining the everyday use of Powershell for most admins and the C2 framework of Empire, makes for a deadly combination that may go unnoticed by defenders.
Method to the Madness
With all the open source post-exploitation and testing frameworks available, one might wonder why Powershell Empire is being used for this blog post. The popularity of this tool makes it well known to attackers, but defenders as well. In my home lab, I try out a number of exploits to see if my current setup can detect them or not.
Instead of trying out the latest APT super "leet" malware strain, I have decided to go back to the basics. Who cares if I am able to detect those APT samples when well known tools like nmap, Metasploit, and Powershell Empire are strolling right past our defenses?
To save your time and your eyes from reading, I will forgo explaining the ins and outs of Powershell Empire. In addition to the github page: https://github.com/EmpireProject/Empire , there are a number of great articles that will assist in getting a listener and module up and running.
I think it's best to just install Empire, and start playing around with all the different modules and listener types (on networks you have permission) that it has to offer.
For the purposes of this article, we will assume an unsuspecting user has opened and executed a malicious file. A bat file was opened on the victim Windows workstation which contained a Powershell script that opened a backdoor to our attacking Kali machine.
There are a number of ways defenders could go about responding to this incident, however I will break up the sections between host and network analysis and explain the pros and cons of each.
Host Based Intrusion Detection
The victim workstation in this case is a fully patched Windows 10 VM with Sysmon, and Powershell logging. In addition to Windows Defender, I am utilizing Sophos' Intercept X EDR product (https://www.sophos.com/en-us/products/intercept-x.aspx). It should be noted that both security products detected and prevented each of the default Empire files. Unfortunately, we had to do some finagling to get our C2 up and talking.
Right away I received an alert for the malicious file.
Besides the breakdown of the detected threat, the Sophos product also provides the defender with a process map to trace back exactly what happened. In my opinion, having this information early in the incident response process would be of great value to understand what to block and what logs to start scouring.
This is where logging comes of great value. In addition to Sysmon event logging, I will also utilize Powershell script block logging. Verbose logging is not enabled on this system, so only potentially harmful scripts are logged. Your mileage may vary.
This type of logging allows great visibility into Powershell commands that may be of interest to an analyst. Located in the Event Viewer, we can easily get a sense of what code was run. The best thing is both the encoded and decoded commands are logged for your viewing!
First it may be helpful to see if we can find the network connections that were detected by the EDR product.
For the purposes of this research, the C2 and victim were in the same network. However, it should not be very often that Powershell is used to connect to another host on a different network. If the print isn't too small, you can also see that ATT&CK technique T1218 (https://attack.mitre.org/techniques/T1218/ ). Let's go ahead and see what Powershell commands were logged.
If the event window is too cramped up for you, find a good base64 decoder that works for you.
Network Intrusion Analysis
Although command and control activity can blend in with ICMP, DNS and other custom protocols over commonly used ports, there are still reliable ways to discover anomalous beacon traffic. Some protocols beacon by default (NTP), and we would first need to get a baseline of what normal is before making any definitive conclusions.
Before we break open the PCAP, I like to run suspicious traffic through Zeek and see if anything interesting is returned.
The above command provides us with the top connections by length of time. Port 8080 when used with a little tweaking is commonly used for network proxy traffic. The odd thing is that the top five connections are between the same addresses over that same port. A little suspicious...
We know we may be dealing with C2 traffic, let's take a look at the top connections by URI in Zeek's http.log .
These are somewhat odd URI's. We can jot them down as possible IOC's and move on.
Looking at the time, we can see the request/response traffic is about 5 - 10 seconds apart, which is usually indicative of C2 traffic. Our suspect traffic is traversing over HTTP, which should mean we can view the responses.
*Note: The great thing about the Powershell Empire framework is just how easily options can be changed on the fly. The downside for defenders is that some of the above indicators that could be used in a Snort or Suricata signature could be changed with a few mouse clicks.
Following the streams, it appears that the GET requests are simply check ins for the victim to see if the C2 has any new commands for it to follow. The juicy info should be inside of the POST requests, which must be the attacker issuing commands (privilege escalation, screenshots, etc.).
Over HTTP, we should be able to see the POST method traffic, however it appears that the C2 commands are being encoded. Port 8080 is commonly used for non-secure data transfer. This is another possible IOC to keep track of.
In addition to the URI's, we can also make note of the custom User Agent that is used in the C2 traffic. Again, these items can be changed easily by an attacker and should not be used as concrete IOC's.
While we may not know what system an attacker is utilizing against us, there are some additional indicators to note. Powershell Empire makes use of custom server web pages that may or may not fit the attackers profile (I am not using a Microsoft IIS server on my Kali box).
The above network indicators will be good to track using Zeek, Suricata or Snort or any other network IDS/IPS device. Alone these indicators don't help us much, which is why it is imperative that this information be paired with our host based analysis.
At this point, it would make sense for our analyst to revisit some of the rules in their IDS/IPS of choice and finely tune them for the next attack. Packaging up all the above into an automated analyzer would more likely bring us better return when the next attack rears its ugly head.
These were just a few ways to detect and pull anomalous activity from Powershell Empire C2 activity. Unfortunately, we did not get to discuss memory analysis or further host based analysis using tools like osquery.
As attackers do not usually get fixated on one exploit to use, defenders should also utilize a number of different tools to detect unusual/malicious activity and rely on the community to pair what they have found.
If someone like myself can easily spin up Empire and compromise a hardened environment, we as defenders must not be on the lookout for the next big APT attack. Ready made tools like Empire are just as accessible to attackers who can change the above indicators and possibly slip through our defenses.