PHONY C2 Framework Analysis – Part of APT MuddyWater

 

PHONYC2

Executive Summary:

"Phony C2" is short for "Phony Command and Control." This term refers to a system or server deliberately created to imitate a legitimate Command and Control (C2) server, often used in cyberattacks or malicious software campaigns. 

Based on the series of analyses, we can establish the flow used by the PhonyC2 server as follows:

  1. PhonyC2 is set up on a Ubuntu operating system, utilizing a command-line interface (CLI) based on Python 3.
  2. The PhonyC2 server is configured with specific IP addresses and ports to act as the Command and Control (C2) server for the targeted Windows systems.
  3. The PhonyC2 server provides several command functions, such as "Ex3cut3," "droper," "exit," "list," "payload," "setcommandforall," and "use," allowing the threat actor to interact with the compromised Windows systems.
  4. The payload generated by PhonyC2 is a PowerShell script that downloads a binary file from a predefined GUID and saves it as "db.sqlite" in "C:\ProgramData" on the targeted Windows system.
  5. The "droper" function is used to trigger the dropping process, and the command methods for this process include "Invoke-RestMethod," "Iwr," "Start-BitsTransfer," and "HTTPWebRequest."
  6. After infection, the PhonyC2 server receives a list of infected devices and can query commands on these infected devices.
  7. The PhonyC2 server sends commands to the infected devices, and the infected devices respond after executing the commands.
  8. The PhonyC2 server performs persistence to maintain the connection with the infected devices, even after they restart.
  9. The infected devices periodically send requests to the PhonyC2 server every 10 seconds to ensure they are still connected to the C2.
  10. During communication between the PhonyC2 server and the infected devices, encrypted data paths are used, and some communications appear to use the User-Agent: Googlebot to mimic legitimate traffic.
  11. This flow demonstrates how the PhonyC2 server operates and interacts with the compromised Windows systems, allowing the threat actor to control and maintain access to the infected devices.


Analysis

In the analyzed script, the script creator utilizes a variable named "VPS" for calling IP and PORT. This suggests that the threat actor recommends using the C2 server within the context of a Virtual Private Server (VPS).

analyzed script

Figure 1

The IP and Port will be set at the beginning of the script "Please_Run_Once.py" as the C2 server to be used.

the IP and Port

Figure 2

Once the PhonyC2 framework is set up, when it is executed, it will automatically adapt to the C2 server settings. PhonyC2 has several command functions such as "Ex3cut3," "droper," "exit," "list," "payload," "setcommandforall," and "use".

the PhonyC2

Figure 3

In this case, the operating system suitable for running this Framework is Linux, as the user interface is command-line based and runs on Python version 3. The target of the PhonyC2 exploitation is specifically Windows systems, which is evident from the payloads, dropper, and Ex3cut3 functionalities that are designed for Windows.

command-line

Figure 4

PhonyC2 utilizes PowerShell commands to perform exploitation on the targeted Windows system. When decoding the payload command, which is in base64 format, it reveals the infection phase. In the first script generated by PhonyC2 (as shown in Figure 4), it will produce a PowerShell script that downloads a binary file from a specific GUID specified by the actor. The downloaded binary file will be saved in the "c:\programdata" directory with the filename "db.sqlite".

powershell
Figure 5

As detailed, the payload information generated by figure 4, in the process steps 1 to 3, can be explained in the data below:

Step 1:

In the first step, the script uses two PowerShell commands to run background jobs simultaneously using the Start-Job cmdlet. Each command uses the Invoke-WebRequest cmdlet to download a file from a specified URL. The URL used is "http://91.235.234.130:443/934e36e6-9d5d-4414-a929-62f8319a068a.aspx?WUEPE63FG40=WUEPE63FG40". The downloaded content is saved as a file named "db.sqlite" in the directory "C:\ProgramData".

Step 2:

In the second step, the script uses the Set-Content cmdlet to create a new file named "db.ps1" in the "C:\ProgramData" directory. The content of the "db.ps1" file is generated through a decryption process from a Base64-encoded string.

  • First, the Base64 string is extracted from the given long text and decrypted. This Base64 string contains the encrypted PowerShell code.
  • The Base64 string is decrypted by reversing the encryption process and converted into the corresponding PowerShell code.
  • The resulting PowerShell code from the decryption is then written to the "db.ps1" file.

Step 3:

  • In the third step, the script uses Windows Management Instrumentation (WMI) to create a new process by running PowerShell with several specified options.
  • The previously created "db.ps1" file is executed with PowerShell.
  • The options used are:
    • EP BYPASS: This option ignores the PowerShell Execution Policy, allowing the execution of unsigned code without restrictions.
    • NoP: This option prevents the execution of the PowerShell profile upon startup to avoid running unwanted scripts.
    • W h: This option sets PowerShell to run in a minimized window with administrator rights, hiding the execution from the user's view.
  • After executing the "db.ps1" file, the script waits for 5 seconds (sleep 5).
  • After the delay, the script uses the "rm" (remove) command to delete the "db.sqlite" and "db.ps1" files from the "C:\ProgramData" directory to erase any traces of malicious activity.

The script is designed to carry out a series of actions that include downloading and executing files from an unknown URL, decrypting and executing an encrypted PowerShell code from the "db.ps1" file, and finally removing all evidence of its activities. Ini mencakup seluruh fungsi infeksi yang terjadi pada perintah droper dan Ex3cut3. The dropper function provided by Phony C2 is actually the same as the previous script, it's just different from how the command does the droper.

The script is designed to carry out a series of actions

Figure 6


Figure 6 displays 3 methods of performing the drop using Invoke-RestMethod, Iwr, Start-BitsTransfer, and HTTPWebRequest. The included commands are not significantly different and are only distinguished by how the process of dropping malware on the victim is executed. As for the Ex3cut3 command, it will explain how the script will be executed and the process involved.

Figure 7 refers to the result of the infection flow executed in Figure 4

Figure 7

Figure 7 refers to the result of the infection flow executed in Figure 4, as previously explained. It points to the "db.ps1" file that will be executed and deleted afterward, along with the following folder and files: "c:\programdata", "db.sqlite", and "db.ps1". Each time a user issues a command on the victim, PhonyC2 will send a command transmission to the victim and subsequently receive the results of that command on the C2 server. 

After the infection phase, the server will receive a list of infected devices in the list and can query commands on the infected devices.

the dropper command will be triggered
Figure 8

During the infection process in PhonyC2, the dropper command will be triggered, and it will show the infected host. The dropper command is responsible for dropping and executing the payload on the infected host, which leads to the successful infection.

command-line interface (CLI)

Figure 9


Even if the terminal or command-line interface (CLI) is closed, as long as the C2 server is online and operational, the PhonyC2 will continue running in the background. Whenever a threat actor starts the PhonyC2, there will be a notification or trigger on the front-end display indicating the infection process has been initiated. This notification serves as an alert to the threat actor that the PhonyC2 has been successfully launched and is ready to carry out its malicious activities.

getcommandall

Figure 10

To access the victims, the threat actor can utilize the "getcommandall" command to issue commands to all available victims simultaneously. Alternatively, they can choose specific victims they wish to access by using the command "use <victim_id>." This allows the threat actor to interact with individual victims and execute specific commands tailored to their selection.

commands to the victims

Figure 11

The threat actor can send shell commands to the victims; however, the process takes some time as it requires a few seconds for the results of the command to be obtained. 

commands

Figure 11

The threat actor can also establish persistence to maintain the connection from the victim to the C2 server even if the victim's system is restarted.

persistence mechanism on the system

Figure 12

Based on the provided script, it appears to be creating a persistence mechanism on the system. Below is the flow of the script and its function for persistence:

Flow and Function of the Script for Persistence:

  • The script begins by adding a new registry entry under "HKLM\Software\Microsoft\Windows\CurrentVersion\Run." This registry key is responsible for automatically executing the script each time the system starts up. The new entry is named "NEW," and its value points to the location of the file "C:\intel\utils\utils.jse".
  • The script then creates a directory named "c:\intel\utils" using the mkdir command with the "-f" (Force) parameter.
  • The script changes its working directory to "c:\intel\utils" using the cd command.
  • It then decodes and writes a Base64-encoded payload to the file "c:\intel\utils\utils.jse". The content of "utils.jse" is obfuscated and appears to contain a PowerShell script.
  • The payload in "utils.jse" is responsible for establishing a connection to a remote server, obtaining the system's unique identifier (UUID), and serial number of the hard drive (HDD).
  • The obtained UUID and HDD serial number are combined to generate a unique key ("keyooo").
  • The payload runs an infinite loop with a sleep interval of 6 seconds, repeatedly trying to connect to a remote server using the generated key and sending an HTTP GET request.
  • If the connection to the remote server is successful (response received), the payload decodes and executes the received Base64-encoded content.
  • The loop continues, and the script maintains persistence by repeatedly connecting to the remote server, executing commands, and repeating the process.

One of the capabilities of PhonyC2 is that every 10 seconds, the infected victim will send a request to ensure that it is still connected to the C2 server.

victim

Figure 13: Victim


PhonyC2 will also send requests and receive responses when using the shell command from the C2 server to the victim, which can be observed in a Wireshark capture. These communications are marked with an encrypted data path. Additionally, one of the communication behaviors involves using the User-Agent: Googlebot.


victim

Figure 13: Victim


We can establish the flow used by the PhonyC2 server as follows:


flow

Figure 13: Flow


Based on the analysis and evidence, the PhonyC2 framework is proven to operate on Ubuntu/Linux operating systems. The confirmation of this can be seen from the adjustments made based on the Etag: 2aa6-5c939a3a79153, which is identified as the tag infrastructure used by the threat actor group MuddyWater. This tag is associated with SimpleHelp tools and PhonyC2.

Furthermore, during the examination, it was found that all the servers used by the threat actor group MuddyWater are running on Ubuntu/Linux operating systems. This information solidifies the fact that the PhonyC2 framework is designed to run on Linux systems and is utilized by the threat actors on their Ubuntu/Linux servers.

As a result, the evidence and information gathered during the analysis strongly indicate that the PhonyC2 framework is primarily intended for deployment on Linux systems, and the threat actor group MuddyWater actively utilizes this framework on their Ubuntu/Linux servers for their malicious activities.


Fofa

FOFA finding: https://en.fofa.info/result?qbase64=YmFubmVyPSIyYWE2LTVjOTM5YTNhNzkxNTMi



The findings were obtained from the FOFA Search engine using the Etag: 2aa6-5c939a3a79153. The use of the Ubuntu operating system facilitates their use of the PhonyC2, which operates via the CLI (Command Line Interface) with Python scripts.

Based on the infection flow and how PhonyC2 conducts its infection and communication, I have created YARA Rules and Snort rules using the available sources in the provided link:

https://drive.google.com/drive/folders/19X-sIbOc2QIYB1aThDTLnELtTVh4Uogg?usp=sharing





0 Comments