NOTE: This post was written by Jared Myers of the RSA Incident Response Team. It original appeared on RSA's Speaking of Security blog site: https://blogs.rsa.com/wolves-among-us-abusing-trusted-providers-malware-operations/
Within the past year the RSA Incident Response (IR) team has worked multiple APT engagements where they’ve identified the adversary’s malware using a unique method of determining its Command and Control (C2) server. By leveraging trusted content providers, such as popular shopping sites and discussion forums, adversaries can perform operations within a network in plain sight. By replacing a hard-coded beacon address within malware with a simple user name, binaries can transmit a basic lookup for activity made by fake accounts on public discussion forums that contain dynamic IP addresses for communications.
As an example, RSA IR discovered use of malware known as PNGRAT during a recent response effort. PNGRAT, which has since been publicly documented as ZoxPNG, is a substantially equipped trojan with the ability to manage files, enumerate and control processes, and execute commands. In this particular variant, there were additional features that allowed the malware to collect stored HTTP credentials from the registry of the compromised system, as well as monitor for RDP connections. More importantly, these samples of PNGRAT did not contain a hardcoded IP address or domain for C2 communications.
RSA has noted many adversaries who use public services for C2 architecture in order to prevent detection. However, the method in which the C2 IP address is acquired from these samples is considered unique. In this PNGRAT variant, the malware used the method of retrieving its download instructions from Microsoft’s Technet website. By connecting to Technet and retrieving the user profile for a hardcoded user account, PNGRAT retrieved an IP address for further C2 connections. This IP address is stored and encoded within the user profile. Though encoded, the address did have a particular header and footer that made it obvious to those who knew to look for it:
@MICR0S0FTabcdabcdC0RP0RATI0N
These C2 messages were made into legitimate discussions on the Microsoft Technet forums, such as shown in the figure below. In the example highlighted in the red box, the decoded IP Address is 127.0.0.1.
The malware searches for this value and then retrieves the encoded data stored between “@MICR0S0FT” and “C0RP0RATI0N“. This value is the result of a fairly simple encoding routine. Every two bytes represents a single number, which when combined back together creates an octet of an IP address.
As described in the example below, the IP address if 192.168.1.1 can be encoded as amyzbabq and would be stored on Technet as:
@MICR0S0FTamyzbabqC0RP0RATI0N
Each octet of the IP Address is encoded using two characters. The table below breaks down the original values for each set of characters.
| First set | Second set | Third set | Fourth set |
| am | yz | ba | bq |
| 192 | 168 | 1 | 1 |
To determine the first octet simple logic is applied to each character of the first set.
The decimal value for each character is obtained. For the set of ‘am’, this would be 97 for ASCII letter ‘a’ and 109 for ASCII letter ‘m’.
The second value, 109, is then bit-shifted left by 4. The resulting value is then added to the value of the first character, 97.
The routine then subtracts the value of 113 (0x71) from the sum and cast as a single byte (commonly seen as “& 0xFF”). The resulting value is 192, the first octet of the IP address.
The same logic is followed for the remaining octets.
| Operation | Resulting Value | |
| 1 | 109 << 4 | 0x06D0 (1744) |
| 2 | 1744 + 97 | 0x0731 (1841) |
| 3 | 1841 – 113 | 0x06C0 (1728) |
| 4 | 1728 & 0xFF | 0x00C0 (192) |
It should be noted that several letter combinations could produce the same value once decoded. This is demonstrated in the example 192.168.1.1, which we show in an encoded form as ‘amyzbabq’, both the value ‘ba’ and ‘bq’ will properly decode to the value of 1.
The retrieval of this traffic is stored in plain text and can be easily tracked by a comprehensive network-monitoring solution. RSA’s Security Analytics and ECAT can both be leveraged to assist security hunters in detecting this activity, and an adversary early in their campaign. Using a custom LUA Parser for Security Analytics, security can be alerted to the presence of this malware in their environment by inspecting all network traffic for this unique encoding structure. Instead of passively allowing all traffic from a trusted provider, incorporating parsers, like the one provided leaves no packet unsearched. This decoder will detect the activity, decode the IP address, and store it as an indexed value for detailed analysis, under IP Alias (which is illustrated in the image below). This parser is provided along with this blog, along with a Yara Rule for the executables, which can be used independently or ingested into ECAT. The image below illustrates how the alert that will be observed in Security Analytics.
While the attached parser has been tested and used by the RSA IR Team without issue or impact in multiple SA environments for our customers, custom content should always be tested and its performance implications considered before integrating additional content into an organization’s SA infrastructure.
Additionally, RSA has created a simple Python script for automatically decoding these values that can be leveraged or implemented into other internal projects. This file is also provided along with the publication. For more questions about this blog post or other information in general, please contact us at FirstResponse@rsa.com
All of the files that were referenced in this blog can be located in this archive
