Analysis of the behavior of the Pegasus Trojan in the network
The source code for the Pegasus banking Trojan was recently published . Despite the mention of the Carbanak group in the name of the archive, researchers from Minerva Labs denied the Trojan’s involvement in this group and proved their involvement in the Buhtrap (Ratopak) group. Inside the archive is a brief description of the work of the Trojan, its source codes, a description of the bank payment system and data from employees of many Russian banks.
The architecture of the source code of this malware is quite interesting. The functionality is divided into modules assembled into a single binpack at compile time. The compilation process also includes the signature of executable files with a certificate from the tric.pfx file that is not in the archive.
No less curious is the network activity of Pegasus, which, after infection, tries to spread within the domain and is able to proxy the data between the machines using the Mailslot pipes and transport. We focused on studying the characteristics of Trojan network activity and quickly added detections for Pegasus to the PT Network Attack Discovery product. This will allow all its users to timely detect the activity of this trojan and its modifications in its network. In this article I will give a detailed description of the mechanisms of distribution over the network and the interaction between copies of Pegasus.
')
Once on the machine, the main module InstallerExe injects the code into svchost.exe using the Process Hollowing technique and, after initializing the main modules, Pegasus launches several parallel processes:
One of the subsystems in Pegasus is responsible for the horizontal distribution (Lateral Movement) in the Windows network. Distribution is divided into two important stages:
Detection of neighboring machines in the domain is carried out through two API calls:
NetServerEnum, which requires Browser service and WNetOpenEnum / WNetEnumResource calls.
All machines found in the domain are checked if they are already infected. Pegasus queries the generated name of the pipe once every 200 milliseconds more than 20 times in a row. We have used this abnormal behavior as one of the indicators of Pegasus activity in the domain. Having found no signs of infection, the malware moves to the next step - an attempt to replicate.
Replication occurs as follows. Using the found accounts (US) on the host, Pegasus attempts to authenticate on the machine using the SMB protocol to the IPC $ and ADMIN $ balls, and if there is access to IPC $, but there is no access to the ADMIN $, Pegasus concludes that account is not enough and must be marked as invalid. Having gained access to the ADMIN $ balloon, which is an alias for the% windir% folder, the malware tries to determine the architecture of the machine in order to use the appropriate module in the future.
The architecture definition algorithm is based on the headers of the PE files on the remote machine. As such a file, Pegasus tries to read the first 4 kilobytes of notepad.exe from the% windir% folder. The obvious lack of such a method is that on Windows Server 2012, the notebook is located along the path% windir% \ System32.
The location of notepad.exe on Windows 7:
On Windows Server 2012:
Not finding notepad.exe, Pegasus cannot infect the server, even with account information with the necessary permissions. The mere absence of a notebook in% windir% can stop the distribution of Pegasus on Windows Server 2012. Using regedit.exe in this regard is more reliable.
After successfully determining the architecture of the target server, Pegasus downloads a small RSE (Remote Service Exe) dropper with a size of about 10 kilobytes, the task of which is to load the binpack from Pegasus modules through the pipe in open form and transfer control to the Shellcode module. A dropper name is composed in a pseudo-random manner and consists of a string of hexadecimal characters 8 to 15 characters long. The pseudo-random generator is initialized depending on the name of the target machine and will be the same between launches to avoid possible garbage% windir% with past copies of the dropper.
The dropper is checked for integrity and possible removal by the antivirus, after which it is launched by one of two implemented mechanisms - SCM or WMI, and in the first place Pegasus attempts to launch RSE through the WMI mechanism, and only then with the help of Service Control Manager (SCM). This is done for the reason that SCM leaves more traces in the Windows logs. The plans of the creators of Pegasus were other methods of distribution - Wsh Remote, Powershell remoting, Task Scheduler, and a module for executing commands via RDP was under development.
As mentioned above, after a successful launch, the dropper checks and opens the pipe for listening and transfers control to the incoming payload.
Since Pegasus code is injected by the Process Hollowing method into the svchost.exe process, neither the original InstallerExe module in the case of the initial infection, nor the RSE dropper in the distribution case should remain on the disk. If the dropper is still available along a known path, Pegasus deletes it in its own way:
After successful infection, the Domain Replication distribution process begins again.
After Pegasus has access to the account data either from another copy of Pegasus, or from the mod_LogonPasswords module, it will begin broadcasting the UZ data across the domain. Mailing is done using Mailslot's SMB-based mechanism, which allows for unidirectional broadcasting of a small portion of data across a domain. Distribution occurs on a randomly generated slot name and, so that all infected machines in the domain can send and receive data using a single name, the pseudo-random generator for names is initialized from the TARGET_BUILDCHAIN_HASH variable specified in the config when building.
Since the Mailslot mechanism imposes a limit on the maximum packet size, only one UZ is distributed at a time according to the principle of the last distribution time: among all the existing UZ by the domain, the one whose date of last distribution is the oldest is distributed.
The data in Mailslot ah is not transmitted in the clear, but wrapped with three layers of XOR encryption, with the keys being transmitted along with the data. The first data layer is the envelope NetMessageEnvelope with data integrity checking algorithm SHA1, used for all data transmitted over the local network. The 4 bytes of data at the beginning of a packet are the key, which is changed by bit shifts by 5 bits to the right per cycle. Inside the envelope contains XOR coded data structure with the fields of the ultrasound directly and the date of their addition. The 8 byte key is also located at the beginning of the structure, but is applied without shifts. After decoding the structure of the KM, all that remains is to deserialize the individual fields from the ENC_BUFFER structures such as the computer name, the domain name, the user name, and his password. These fields are encrypted using an 8 byte key with offsets. A script to decrypt the Mailslot package and an example of such a package can be found here: script , PCAP .
The mailing period for Mailslot messages in the release version ranges from 20 seconds to 11 minutes.
In addition to sharing accounts, the Mailslot mechanism is used to search for an infected machine with Internet access and to announce Internet access. The envelope NetMessageEnvelope stores the type of message sent. The data exchange between the machine without access and the machine with Internet access is carried out through the pipes.
For two-way communication or transfer of large amounts of data, copies of Pegasus use pipes as a channel of communication. The name of the pipe, although it is also generated by a pseudo-random generator, but depends on the name of the machine and the build, and thus allows the client and server parts to use the same name.
When one-way communication, for example, transfer binpack during replication to another machine, the data is not encrypted and transmitted in the clear. Binpack starts with a SHELLCODE_CONTEXT structure with a length of 561 bytes.
During a two-way transfer, for example, of proxying data between a copy of Pegasus without Internet access and a CnC server, the same NetMessageEnvelope structure with XOR encryption is used, as in the case of Mailslot, since It allows you to distinguish between different types of messages in the id field.
Architecturally, data proxying is performed through a request to transfer a portion of data (PMI_SEND_QUERY), receiving the request id in response, and polling the task status by id (PMI_CHECK_STATUS_QUERY). As a rule, a different Envelope structure is added as a load, adding different functionality and another layer of encryption.
In addition, work with the pipe does not end with the interaction between infected machines. The mod_KBRI_hd module injects cmd.exe code into the processes that intercepts MoveFileExW calls and analyzes all copied data, since this is part of the payment mechanism. If the file being copied contains data interesting to the attackers - payment data, a notification about this is sent to the CnC server. Communication between the mod_KBRI module injected into cmd.exe and a copy of Pegasus is carried out inside the infected machine via a pipe whose name is not generated, but is strictly specified in the source code:
The functionality of the module also includes the substitution of account data on the fly by a template. An example of patterns for search in the screenshot.
For the direct exchange of data with the CnC server, a separate stream is responsible, which every few minutes checks a queue of data chunks from internal processes or from other copies of the malware and sends them to the server.
During the initialization of the mod_NetworkConnectivity module, it conducts a multi-step test of the network connection:
1) Detection of proxy server settings and attempt to connect to www.google.com :
2) Check connection to Microsoft update servers and return data ( authrootseq.txt , authrootstl.cab , rootsupd.exe )
3) Testing HTTPS connections with one of 6i addresses:
Only after passing through all the checks, Pegasus believes that it has the necessary access to the external network and can announce it over the Mailslot domain as a message. And Pegasus can be masked and communicate with the CnC server only during business hours - from 9 to 19 and local time.
Pegasus sends chunks of data wrapped in an envelope with a hash sum calculation in encrypted form using DES encryption in CRYPT_MODE_CBC / PKCS5_PADDING mode. The encryption key depends only on the variable at compile time, and so we can decrypt the traffic between the malware and the server knowing only its BUILDCHAIN_HASH. In the source code inside the archive, this variable had the value 0x7393c9a643eb4a76. The script for decrypting the bounce (Check-in) to the server and an example of such a package can be found here: script , PCAP .
Such content (structure INNER_ENVELOPE) it transfers to the CnC server during the Check-in, or with some data. First, there are 28 bytes of an envelope with a length field and a SHA1 sum.
The same data is transmitted between the machines during proxying through the pipe, but wrapped inside the NetMessageEnvelope envelope known to us with a hash sum and XOR encryption.
The CnC operator can send commands to execute on a copy of Pegasus and messages with commands or other data, for example EID_CREDENTIALS_LIST may contain their own field encryption layers, as we have already seen in the case of broadcast accounts.
First of all, we were interested in detecting Pegasus activity on the network and, after carefully studying the source codes and running it in a test environment, we found those network anomalies and artifacts that clearly indicate the presence of this complex malware on the network. Pegasus can really be called versatile - it actively uses the SMB protocol for sending messages and establishing communication with other copies, extends to other machines and communicates with the CnC server in its own particular way. By establishing a peer-to-peer network in the domain, copies of Pegasus pave the way to the external network and communicate with the CnC server, proxying traffic through each other. Using certificates to sign executable files and accessing Microsoft and Mozilla resources during connection testing makes it difficult to detect its activity and detection on the host.
The Pegasus source code project is quite well structured and described, so in the near future we can expect parts of its code to be borrowed by other malware and the appearance of modifications.
Many of the mechanisms for remote execution of commands and search for these accounts remained unfulfilled, the developers were also going to add the ability to change the shellcode during the implementation process on the fly. And this is not all their ideas.
We have developed several signatures for PT NAD and IDS Suricata, which allow identifying Pegasus-specific network activity at different stages, starting from the very first seconds of its activity. You can find open signatures for Suricata IDS on our github and Twitter , they will automatically go to your Suricata if you use the suricata-update update mechanism.
You can see how the signatures on the activity of Pegasus work in the screenshot below. This is our new product, PT Network Attack Discovery , which identifies incidents and assists in their investigation:
In addition, the following compromise indicators (IC) can be used for detection:
Posted by : Kirill Shipulin from @attackdetection, Twitter | Telegram
The architecture of the source code of this malware is quite interesting. The functionality is divided into modules assembled into a single binpack at compile time. The compilation process also includes the signature of executable files with a certificate from the tric.pfx file that is not in the archive.
No less curious is the network activity of Pegasus, which, after infection, tries to spread within the domain and is able to proxy the data between the machines using the Mailslot pipes and transport. We focused on studying the characteristics of Trojan network activity and quickly added detections for Pegasus to the PT Network Attack Discovery product. This will allow all its users to timely detect the activity of this trojan and its modifications in its network. In this article I will give a detailed description of the mechanisms of distribution over the network and the interaction between copies of Pegasus.
')
Intro
Once on the machine, the main module InstallerExe injects the code into svchost.exe using the Process Hollowing technique and, after initializing the main modules, Pegasus launches several parallel processes:
- Domain Replication - is engaged in intelligence within the network and attempts to spread to other Windows machines.
- Mailslot Listener listens to broadcast mailslot messages with which Pegasus sends out acquired accounts. The slot name is generated at compile time.
- Pipe Server Listener listens to the Windows Pipe with the name generated on behalf of the machine. These pipes are mainly used to detect other copies of Pegasus in the network and their interaction.
- Logon Passwords periodically every few minutes trying to dump account data module from Mimikatz.
- Network Connectivity is responsible for communicating with the CnC server and periodically exchanging messages.
// start transports which links data with our CB-manager pwInitPipeServerAsync(dcmGetServerCallback()); mwInitMailslotServer(dcmGetServerCallback()); ... // start broadcasting creds to other machines cmStartupNetworkBroadcaster(); Domain Replication
One of the subsystems in Pegasus is responsible for the horizontal distribution (Lateral Movement) in the Windows network. Distribution is divided into two important stages:
- Detection of neighboring machines.
- Attempt to replicate on the machine.
Detection of neighboring machines in the domain is carried out through two API calls:
NetServerEnum, which requires Browser service and WNetOpenEnum / WNetEnumResource calls.All machines found in the domain are checked if they are already infected. Pegasus queries the generated name of the pipe once every 200 milliseconds more than 20 times in a row. We have used this abnormal behavior as one of the indicators of Pegasus activity in the domain. Having found no signs of infection, the malware moves to the next step - an attempt to replicate.
Replication occurs as follows. Using the found accounts (US) on the host, Pegasus attempts to authenticate on the machine using the SMB protocol to the IPC $ and ADMIN $ balls, and if there is access to IPC $, but there is no access to the ADMIN $, Pegasus concludes that account is not enough and must be marked as invalid. Having gained access to the ADMIN $ balloon, which is an alias for the% windir% folder, the malware tries to determine the architecture of the machine in order to use the appropriate module in the future.The architecture definition algorithm is based on the headers of the PE files on the remote machine. As such a file, Pegasus tries to read the first 4 kilobytes of notepad.exe from the% windir% folder. The obvious lack of such a method is that on Windows Server 2012, the notebook is located along the path% windir% \ System32.
The location of notepad.exe on Windows 7:
C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe C:\Windows\notepad.exe On Windows Server 2012:
C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe Not finding notepad.exe, Pegasus cannot infect the server, even with account information with the necessary permissions. The mere absence of a notebook in% windir% can stop the distribution of Pegasus on Windows Server 2012. Using regedit.exe in this regard is more reliable.
After successfully determining the architecture of the target server, Pegasus downloads a small RSE (Remote Service Exe) dropper with a size of about 10 kilobytes, the task of which is to load the binpack from Pegasus modules through the pipe in open form and transfer control to the Shellcode module. A dropper name is composed in a pseudo-random manner and consists of a string of hexadecimal characters 8 to 15 characters long. The pseudo-random generator is initialized depending on the name of the target machine and will be the same between launches to avoid possible garbage% windir% with past copies of the dropper.
The dropper is checked for integrity and possible removal by the antivirus, after which it is launched by one of two implemented mechanisms - SCM or WMI, and in the first place Pegasus attempts to launch RSE through the WMI mechanism, and only then with the help of Service Control Manager (SCM). This is done for the reason that SCM leaves more traces in the Windows logs. The plans of the creators of Pegasus were other methods of distribution - Wsh Remote, Powershell remoting, Task Scheduler, and a module for executing commands via RDP was under development.
As mentioned above, after a successful launch, the dropper checks and opens the pipe for listening and transfers control to the incoming payload.
Since Pegasus code is injected by the Process Hollowing method into the svchost.exe process, neither the original InstallerExe module in the case of the initial infection, nor the RSE dropper in the distribution case should remain on the disk. If the dropper is still available along a known path, Pegasus deletes it in its own way:
- overwriting the file contents with random data;
- overwriting with empty data (zeros);
- rename file;
- delete the file.
After successful infection, the Domain Replication distribution process begins again.
Mailslot works
After Pegasus has access to the account data either from another copy of Pegasus, or from the mod_LogonPasswords module, it will begin broadcasting the UZ data across the domain. Mailing is done using Mailslot's SMB-based mechanism, which allows for unidirectional broadcasting of a small portion of data across a domain. Distribution occurs on a randomly generated slot name and, so that all infected machines in the domain can send and receive data using a single name, the pseudo-random generator for names is initialized from the TARGET_BUILDCHAIN_HASH variable specified in the config when building.Since the Mailslot mechanism imposes a limit on the maximum packet size, only one UZ is distributed at a time according to the principle of the last distribution time: among all the existing UZ by the domain, the one whose date of last distribution is the oldest is distributed.
The data in Mailslot ah is not transmitted in the clear, but wrapped with three layers of XOR encryption, with the keys being transmitted along with the data. The first data layer is the envelope NetMessageEnvelope with data integrity checking algorithm SHA1, used for all data transmitted over the local network. The 4 bytes of data at the beginning of a packet are the key, which is changed by bit shifts by 5 bits to the right per cycle. Inside the envelope contains XOR coded data structure with the fields of the ultrasound directly and the date of their addition. The 8 byte key is also located at the beginning of the structure, but is applied without shifts. After decoding the structure of the KM, all that remains is to deserialize the individual fields from the ENC_BUFFER structures such as the computer name, the domain name, the user name, and his password. These fields are encrypted using an 8 byte key with offsets. A script to decrypt the Mailslot package and an example of such a package can be found here: script , PCAP .The mailing period for Mailslot messages in the release version ranges from 20 seconds to 11 minutes.
// some random wait before making next step DbgPrint("going to sleep"); #ifdef _DEBUG // debug - 2-5 s Sleep(rg.rgGetRnd(&rg, 2000, 5000)); #else // release - 20 - 650 s //Sleep(rg.rgGetRnd(&rg, 2000, 65000) * 10); Sleep(rg.rgGetRnd(&rg, 2000, 15000)); #endif In addition to sharing accounts, the Mailslot mechanism is used to search for an infected machine with Internet access and to announce Internet access. The envelope NetMessageEnvelope stores the type of message sent. The data exchange between the machine without access and the machine with Internet access is carried out through the pipes.
Pipe works
For two-way communication or transfer of large amounts of data, copies of Pegasus use pipes as a channel of communication. The name of the pipe, although it is also generated by a pseudo-random generator, but depends on the name of the machine and the build, and thus allows the client and server parts to use the same name.
When one-way communication, for example, transfer binpack during replication to another machine, the data is not encrypted and transmitted in the clear. Binpack starts with a SHELLCODE_CONTEXT structure with a length of 561 bytes.
During a two-way transfer, for example, of proxying data between a copy of Pegasus without Internet access and a CnC server, the same NetMessageEnvelope structure with XOR encryption is used, as in the case of Mailslot, since It allows you to distinguish between different types of messages in the id field.
Architecturally, data proxying is performed through a request to transfer a portion of data (PMI_SEND_QUERY), receiving the request id in response, and polling the task status by id (PMI_CHECK_STATUS_QUERY). As a rule, a different Envelope structure is added as a load, adding different functionality and another layer of encryption.
In addition, work with the pipe does not end with the interaction between infected machines. The mod_KBRI_hd module injects cmd.exe code into the processes that intercepts MoveFileExW calls and analyzes all copied data, since this is part of the payment mechanism. If the file being copied contains data interesting to the attackers - payment data, a notification about this is sent to the CnC server. Communication between the mod_KBRI module injected into cmd.exe and a copy of Pegasus is carried out inside the infected machine via a pipe whose name is not generated, but is strictly specified in the source code:
\.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2 The functionality of the module also includes the substitution of account data on the fly by a template. An example of patterns for search in the screenshot.Cnc traffic
For the direct exchange of data with the CnC server, a separate stream is responsible, which every few minutes checks a queue of data chunks from internal processes or from other copies of the malware and sends them to the server.
During the initialization of the mod_NetworkConnectivity module, it conducts a multi-step test of the network connection:
1) Detection of proxy server settings and attempt to connect to www.google.com :
- In the registry \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Internet Settings.
- Via WPAD (call WinHttpGetProxyForUrl).
- Through the proxy server configuration for the current user (call WinHttpGetIEProxyConfigForCurrentUser).
2) Check connection to Microsoft update servers and return data ( authrootseq.txt , authrootstl.cab , rootsupd.exe )
3) Testing HTTPS connections with one of 6i addresses:
- safebrowsing.google.com
- aus3.mozilla.org
- addons.mozilla.org
- fhr.data.mozilla.com
- versioncheck-bg.addons.mozilla.org
- services.addons.mozilla.org
Only after passing through all the checks, Pegasus believes that it has the necessary access to the external network and can announce it over the Mailslot domain as a message. And Pegasus can be masked and communicate with the CnC server only during business hours - from 9 to 19 and local time.
Pegasus sends chunks of data wrapped in an envelope with a hash sum calculation in encrypted form using DES encryption in CRYPT_MODE_CBC / PKCS5_PADDING mode. The encryption key depends only on the variable at compile time, and so we can decrypt the traffic between the malware and the server knowing only its BUILDCHAIN_HASH. In the source code inside the archive, this variable had the value 0x7393c9a643eb4a76. The script for decrypting the bounce (Check-in) to the server and an example of such a package can be found here: script , PCAP .
Such content (structure INNER_ENVELOPE) it transfers to the CnC server during the Check-in, or with some data. First, there are 28 bytes of an envelope with a length field and a SHA1 sum.
The same data is transmitted between the machines during proxying through the pipe, but wrapped inside the NetMessageEnvelope envelope known to us with a hash sum and XOR encryption.
The CnC operator can send commands to execute on a copy of Pegasus and messages with commands or other data, for example EID_CREDENTIALS_LIST may contain their own field encryption layers, as we have already seen in the case of broadcast accounts.
Detection
First of all, we were interested in detecting Pegasus activity on the network and, after carefully studying the source codes and running it in a test environment, we found those network anomalies and artifacts that clearly indicate the presence of this complex malware on the network. Pegasus can really be called versatile - it actively uses the SMB protocol for sending messages and establishing communication with other copies, extends to other machines and communicates with the CnC server in its own particular way. By establishing a peer-to-peer network in the domain, copies of Pegasus pave the way to the external network and communicate with the CnC server, proxying traffic through each other. Using certificates to sign executable files and accessing Microsoft and Mozilla resources during connection testing makes it difficult to detect its activity and detection on the host.
The Pegasus source code project is quite well structured and described, so in the near future we can expect parts of its code to be borrowed by other malware and the appearance of modifications.
Many of the mechanisms for remote execution of commands and search for these accounts remained unfulfilled, the developers were also going to add the ability to change the shellcode during the implementation process on the fly. And this is not all their ideas.
We have developed several signatures for PT NAD and IDS Suricata, which allow identifying Pegasus-specific network activity at different stages, starting from the very first seconds of its activity. You can find open signatures for Suricata IDS on our github and Twitter , they will automatically go to your Suricata if you use the suricata-update update mechanism.
You can see how the signatures on the activity of Pegasus work in the screenshot below. This is our new product, PT Network Attack Discovery , which identifies incidents and assists in their investigation:
In addition, the following compromise indicators (IC) can be used for detection:
MAILSLOT \ 46CA075C165CBB2786 pipe \ pg0F9EC0DB75F67E1DBEFB3AFA2 hxxp: //denwer/pegasus/index.php hxxp: //mp3.ucrazy.org/music/index.php hxxp: //support.zakon-auto.net/tuning/index.asp hxxp: //video.tnt-online.info/tnt-comedy-tv/stream.php
Posted by : Kirill Shipulin from @attackdetection, Twitter | Telegram
Source: https://habr.com/ru/post/418017/
All Articles