In the beginning of July 2017, ActiveCanopy Cyber Operations Center was called to support an incident response for a healthcare network system. During the incident response, a malicious file was identified on a compromised host on the network system. After some investigative research, it was determined the file is a part of the PowerShell Empire framework. The PowerShell Empire framework – which was introduced in 2015 at a Las Vegas Security conference allows attackers to run PowerShell agents to rapidly deploy post-exploitation modules ranging from key loggers to Windows Password dumping capabilities and adaptable communications to evade network detection.


Process Analysis

ActiveCanopy traced each type of hidden Powershell attack as depicted below in Figure 1 and 2. These depictions represent the process flow from start to end of the Powershell set of attacks and the commands that were executed along the way.  Figure 1 highlights the full Powershell set of events that was initiated in a hidden registry key where as Figure 2 shows an hidden WMI Powershell.


Based on an analysis of the C# keylogger, ActiveCanopy determined that data from this keylogger was written to the host in “users” temp directory named WebD01 as depicted in Figure 3 and appears to have been uploaded using the “index.jsp” upload call.  Exfiltrated data appears to have then deleted.

Figure 1 Powershell Activity that fully completed


Figure 2 Powershell Activity that failed after Index.asp call


Figure 3 Exfiltration Directory


File Analysis

After a first pass inspection the index.asp file is unreadable and not detected by file tools as a known type. The strings of the file represent data as seen below in Figure 4. The malicious is file named ‘index.asp’ this file is not detected by Symantec anti-virus nor does it appear on Virus Total.

Figure 4 Strings Contained within index.asp


During the investigation it was determined there are several steps which create the staging process of this attack that is summarized below in Figure 5. The file ‘index.asp’ is the staging component in this process. The staging process works together with the command and control server to create an agent on the victim system. The agent accepts commands and interacts with the listener on the command and control infrastructure.

Figure 5 – Attack Summary


The PowerShell Empire framework agent can be delivered in several ways. Although ActiveCanopy was unable to determine which vector was used in this attack, it is common that the attacker would attempt to infiltrate the system via a spear phishing email. The spear phishing email could contain a malicious link or hidden iframe or an attachment that would direct the user to download additional malicious macros, DLL’s or batch files. In this instance it is possible the victim downloaded a malicious ‘.hta’ attachment which was then executed via the ‘mshta.exe’ windows process as shown below in Figure 6.

Figure 6 – MSHTA.EXE Windows Process


From the above output, analysts surmise that the framework is executed via a VB script. The VB script will then invoke a small IEX download cradle which would initiate and execute the ‘index.asp’ stage as listed in step 1. The communication to the command and control server was BASE64 encoded. By decoding the BASE64 we can reveal the IEX downloader and URL.


 To remain present on the victim system as depicted in Figure 7, a key is created in the system registry named ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg\JavaUpdateSheduller’. From the spelling of this key and the additional subkeys created, analysts concluded that this is an attempt to avoid detection by hiding the additional ‘Run’ subkey and masquerading as a known software product. Additionally, by converting the date subkeys, ActiveCanopy Cyber Operations Center can hypothesis that this attack may have occurred around the 19th of June 2017.

Figure 7 – PowerShell Empire Agent Persistence


Figure 8 – Date Created: PowerShell Empire Agent Persistence Registry Key


In addition to the above hidden registry key entry, analysts discovered another hidden persistence Powershell setting that is added in WMI, depicted below, that was set to run a base64 encoded Powershell script.  Unfortunately, the use of base64 encoded Powershell commands will bypass typical Powershell execution restrictions.  This WMI consumer is set to run every day at 04:00 local time or 09:00 GMT.


 Figure 9 – Date Created: PowerShell Empire Agent Hidden WMI Persistence Registry Key


The above base64 decodes to the following.

Figure 10 – IEX Downloader URL


The stager (index.asp) is XOR encrypted with a staging key of #)K%7U~c+wLzEY.m2{oG6f3/X-qPJ5?1this is derived from the command and control server database config. During this activity the key-negotiation stager key is randomized on a per server basis, however this will be static for each server instance. The staging key is sent with the launcher in order to decrypt the stager. In these instances the key will change from stager to stager and will be burned as a result. The stager is delivered ultimately to install an agent that of which will be used to communicate with the victim.


To decrypt the stager, analyst must use a common format. To do this, the investigator used PowerShell for consistency, however any other scripting language can be used to accomplish this task. First, the investigator took the liberty that the key is in ASCII format and convert it to a byte array.


# convert key string to byte array

$kString = ‘#)K%7U~c+wLzEY.m2{oG6f3/X-qPJ5?1’

$key = [System.Text.Encoding]::ASCII.GetBytes($kString)

Next we take the hex output of the ‘index.asp’ file and convert it also to a byte array.


# convert the encrypted stager payload from hex to byte array

$pHex = “655c0566631c1[HEX ENCODED FILE]12d0b24383b172d0323771c00335”

$pHexCount = $pHex.Length

Once completed we create a new byte array for the actual payload.


# create new byte array for payload

$payload = ,0 * ($pHexCount / 2)

for($i=0; $i -lt $pHexCount; $i+=2)

{# convert each char pair to bytes (a pair of chars represent a byte)

$payload[$i / 2] = [System.Convert]::ToByte($pHex.Substring($i, 2), 16)


Lastly we must XOR the two.


# XOR the two byte arrays and concatenate the resulting bytes as chars

$decryptedString = “”

for ($i = 0; $i -lt $payload.Count; $i++){

$decryptedString += [char]($payload[$i] -bxor $key[$i % $key.Length])


The result is the decoded ‘index.asp’ stager file.

Figure 11 – Portion of decoded ‘index.asp’


Once the stager is decrypted, investigators are able to see that it generates a randomized RSA private/public key pair in memory and uses the AES staging key to post the encrypted RSA public key to the command and control server as seen in the step 2 of the summary graphic.

Figure 12 – RSA / AES encryption functions


Lastly the agent decrypts the values, gathers basic system information, and posts this information encrypted with the new AES session key to command and control server using a POST request and value of ‘index.jsp’ in the URI as seen in the image below. At this point the agent is completely set up and starts its beaconing behavior. This behavior is present in step 3 of the summary graphic.

Figure 13 – PowerShell Empire Post Agent Install




Once the malicious agent is dropped to the system, the malicious process will connect to the IP address 198.7.57[.]168 over port 443 in order to send gathered system information and to await commands. From a brief look into the IP address we see it has resolved to two domains in the past koof[.]us and gowdb[.]net.

Figure 14 – Malicious IP Resolution


Further analysis of the koof[.]us domain shows a link.href reference, this could be indicative that the threat actors use malicious iframes in their attack chain to infiltrate the target systems as well as spear phishing emails.

Figure 15 – Possible malicious iframe used in attack scenarios


Figure 16 – Possibly related domain Koof[dot]com Whois Registration


File Information

The table below details the analyzed or created files on the system.

File Name File Size MD5
index.asp 2,897 bytes 14921fded6ad2b1fef26565877f69707
index.asp (decoded) 2,897 bytes a7d03355415c3f7522d57f1229a3b229

Table 1 – File Information



ActiveCanopy Cyber Operations Center recommens using the indicators of compromise in Table 2 below to update perimeter defense systems. In this instance the file ‘index.asp’ was XOR encoded with a multi-byte key and would most likely be transmitted undetected. Logs should be monitored for malicious activity and blocking rules implemented for IP addresses without a legitimate business use case.



Possible Related C&C Domain(s) koof[.]us gowdb[.]net
C&C IP Address 198.7.57[.]168  
User Agent(s) mozilla/5.0 (windows nt 6.1; wow64; trident/7.0; rv:11.0) Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0
MD5(s) 14921fded6ad2b1fef26565877f69707 a7d03355415c3f7522d57f1229a3b229
Filename(s) index.asp index.jsp

Table 2 – Indicators of Compromise Information