Article Content After first uncovering the OilRig group in May 2016, Unit 42 has continued to monitor, observe, and track their activities and evolution over time Since then, OilRig has been heavily researched by the rest of the industry and has been given additional names such as APT34 and Helix Kitten The OilRig group is not particularly sophisticated but is extremely persistent in the pursuit of their mission objective and, unlike other some other espionage motivated adversaries, are much more willing to deviate from their existing attack methodologies and use novel techniques to accomplish their objectives Over time, through our research we have been able to reveal specific details of how their attacks are executed, the tools they use, and even what their development cycle may be like by tracking their use of VirusTotal as a detection check system Due to the nature of the data we had access to however, our perspective was primarily from a target or victim perspective which is generally limited to the artifacts at the time of attack Recently, a data dump was leaked and made available to the public claiming to be data in relation to OilRig activity from the operations side We retrieved the data dump, which included credential dumps, backdoors, webshells, and other files of interest Several media outlets and other researchers have since performed their own evaluation, and in our assessment, we found the artifacts contained in data dump are indeed consistent with known OilRig operations and toolsets In addition, the data dump allowed us to retroactively compare our previous research with OilRig’s operational data This allowed us to fill in previously existing gaps of OilRig’s attack life cycle in addition to validating the accuracy of our research By analyzing the data dump, we have been able to identify exactly how the BONDUPDATER backdoor and its server component functions, the appearance and functionality of several webshells in deployment by OilRig, each of these tools’ internal operational names, and a better understanding of how widespread the OilRig operations may actually be from a global perspective The organizations possibly under attack by OilRig is widely-spread across the spectrum of industry verticals, spanning from government, media, energy, transportation and logistics, and technology service providers In total we identified nearly 13,000 stolen credentials, over 100 deployed webshells, and roughly a dozen backdoor sessions into compromised hosts across 27 countries, 97 organizations, and 18 industries The initial claim included several screenshots of systems potentially in use by OilRig operators for attacks, a script that appeared to be used for DNS hijacking, and a password protected archive with the filename Glimpse.rar purporting to contain the command and control server panel for an OilRig backdoor Soon after, a Twitter account with the user handle @dookhtegan appeared claiming they also had access to data dumps involving internal tools and data used by the OilRig group, as seen in Figure 1 This account used an image from 2004 of a high-profile Iranian asylum seeker named Mehdy Kavousi who famously sewed his eyes and mouth shut to signify that rejecting his asylum claim and sending him back to Iran would be akin to putting him to death It is unknown why this specific image was chosen, other than perhaps as a symbol of protest Since the initial account creation, a stylized version of the original has been substituted as the profile image, making it far more difficult to understand who the original individual was Figure 1 Tweets by @dookhtegan providing files associated with the OilRig leak This account continued a series of tweets voicing protest against the OilRig group and attributing its operations with a specific nation state and organization Unit 42 is unable to validate this level of attribution, but a 2018 report from the United States National Counterintelligence and Security Center stated the OilRig group originates from an Iranian nexus The account continued to post tweets with direct links to operational data dumps hosted on an anonymous file sharing service The files posted included the previously password protected archive Glimpse.rar, as well as new archives containing hundreds of harvested credentials from compromised organizations along with details on exposed login prompts There were also links to webshells previously and possibly currently deployed,  the webshell source codes, as well as another backdoor and its server component This account mirrors the previous messages of exposing the OilRig group but no longer contains links to data dumps, instead instructing those that are interested in the data to join them in a private Telegram channel Figure 2 shows this second Twitter account providing a Telegram channel to leak the data Figure 2 The affected organizations spread across the spectrum of industry verticals, spanning from government, media, energy, transportation and logistics, and technology service providers While we are unable to confirm the validity of the documents detailing individual operators simply due to a lack of visibility into that realm, we also have no reason to doubt their validity either An interesting artifact we found in the data dump are the OilRig threat actors’ own internal names of various tools we have been tracking Table 1 provides the internal operational names and the names we use to track these tools Tools exposed in the OilRig data leak with their internal names mapped to the names used by the security community Credential Dumps In our analysis, we found that a total of fifteen organizations had their credentials stolen in some fashion and stored in text files for the OilRig group to then abuse for additional attacks The types of organizations listed in this data dump spread across multiple industry verticals but were all largely located in the Middle East region This type of activity becomes significantly harder to detect compared to using custom tools as the adversary masquerades as a legitimate user while most protections are intended to catch malware In our past research, based off artifacts we had gathered, we had internally postulated the OilRig group likely had a propensity to immediately attempt to escalate privileges once they have their initial compromise, then try to move laterally into the local Microsoft Exchange server where they would then able to harvest more credentials and implant additional tools such as webshells and IIS backdoors In a presentation provided by a FireEye researcher, they documented this exact attack lifecycle for incidents associated with OilRig in addition to be deploying a post-exploitation toolkit called Ruler within their attack playbook as well Ruler is an open-source penetration testing toolkit which is predicated on being able to access Outlook Web Access (OWA) or OWA via stolen credentials, then abusing built-in functions to perform a variety of actions including retrieving the Global Address List, setting malicious email rules, and in OilRig’s case, performing remote code execution The specific function of Ruler the OilRig group was using is the Ruler.Homepage function This function abuses a capability in Microsoft Outlook which allows an administrator or a user to set a default homepage for any folder inside their inbox Using stolen credentials, the operator would use Ruler to send commands to the target organization’s OWA instance via an RPC protocol which would then remotely set an arbitrary homepage for the compromised inbox’s folders The operator would then include commands in the homepage to automatically retrieve and execute malicious code In OilRig’s case, they included commands to retrieve and execute a backdoor, immediately giving them access to the endpoint in use by the user whose credentials had been stolen Backdoors The data dump included two backdoors that we had previously associated with the OilRig threat group, both of which we had previously referred to as BONDUPDATER Generally speaking, we are able to retrieve the implant or payload involved in an attack but are generally blind to the server side component This data dump provided the backdoors and their associated server components which provides us a different perspective on how the backdoors function In addition, we discovered that the backdoors are actually called Glimpse and Poison Frog internally by OilRig and are functionally two different tools Glimpse The Glimpse tool within the data dump is related to the updated BONDUPDATER tool that we discovered being delivered to a Middle East government organization in a report we published on September 2018 The data dump included the following three requisite components of the Glimpse tool seen in Table 2, as well as a Read me.txt file that explains how to set up and use Glimpse Component Description   Agent Powershell scripts meant to run on compromised systems The three components of the Glimpse tool Glimpse is a PowerShell script that contains the comment version 2.2, which suggests the OilRig group considers this a specific version of the tool and that it likely has included prior versions The Glimpse panel, versioned “v1.0.5” is the tool that the actor uses to organize the various agents installed on compromised systems The panel allows the actors to issue commands in addition to uploading files to and downloading files from the compromised endpoints According to the compilation time, the developer of the Glimpse panel created this tool on September 1, 2018 Figure 3 shows the main Glimpse panel with three different agents listed in a test environment Figure 3 Figure 4 Figure 5 shows the result viewer window showing the results of the issued command Figure 5 The Result Viewer showing the results of an issued command  The server portion of Glimpse works in unison with the panel by acting as a DNS server, which is written in JavaScript and runs in the Node.js runtime The server has a filename of srvr.js, which according to the Read me.txt file is meant to be run using forever start srvr.js in Node.js Figure 6 The Glimpse server issuing a command to an agent and receiving the results of the command Poison Frog The second backdoor included in the data dump is named Poison Frog The dataset includes both the agent that the actor would install on targeted systems and the server that would allow the actor to interact with compromised systems The Poison Frog tool appears to be a variant of BONDUPDATER used in targeted attacks in the Middle East, as reported by FireEye in December 2017 Table 3 shows the files associated with the agent included in the data dump, of which the dUpdater.ps1 portion of Poison Frog appears to be the initial variant of BONDUPDATER that uses DNS tunneling for its C2 channel as discussed in our recent blog discussing OilRig’s DNS tunneling protocols Interestingly, both of these Poison Frog agent scripts were configured to use the domain myleftheart[.]com as its C2 server though we have not seen this domain in any attacks, and we were unable to associate it with any known OilRig infrastructure Files associated with the Poison Frog agent provided in the leak Like the Glimpse C2 server, the Poison Frog server was written in JavaScript and will run in Node.js The headers included in this batch script looked very familiar, as we had seen a very similar batch script provided via the HTTP C2 channel for the Helminth backdoor delivered by a Clayslide delivery document as we reported in October 2016 (SHA256: 903b6d948c16dc92b69fe1de76cf64ab8377893770bf47c29bf91f3fd987f996) Figure 7 The three webshells included in the dump had names HyperShell, HighShell, and Minion, but it appears that Minion is likely a variant of HighShell based on code, filename, and functionality overlaps In addition to the actual webshells in use by OilRig, the data dump includes lists of existing deployments of webshells hosted on compromised websites Over 100 links to webshells are listed, spanning across 87 organizations in 26 countries across four continents as seen in Figure 8 Figure 8 Geographic location of webshells of impacted organizations Hypershell The HyperShell webshell included in the data dump (SHA256: e483eee77fcc5ef11d5bf33a4179312753b62ec9a247dd14528cc797e7632d99) is an example of the 3DES variant of the TwoFace loader that we called TwoFace++ in as we reported in July 2017 The initial TwoFace loader samples decrypted an embedded webshell using an actor provided key, which was modified by using simple arithmetic operators (“+” or “-” specifically) and a salt string embedded within the loader webshell, whose result decrypts an embedded payload using simple arithmetic operators (again, “+” or “-” specifically) Unlike the initial TwoFace loader, the TwoFace++ loader used the 3DES cipher and a SHA256 hash of a string provided by the actor and used as a key, so we were unable to extract the embedded webshells as we were unable to determine the actor provided key However, the HyperShell sample in this dump provided the necessary information to determine the actor-provided key needed to decrypt its embedded webshell Like many initial TwoFace loader samples, the HyperShell sample includes a string within the HTML tags <pre> and </pre> that is displayed in the browser if a password is not supplied and/or the TwoFace++ loader is unable to extract the embedded payload webshell The pre tags within the HyperShell sample are: <pre><%= Server.HtmlEncode(“NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a”) %></pre> Figure 9 shows HyperShell displaying the content within the “pre” tags within the browser Figure 9 HyperShell displaying the password within <pre> tags We determined the string in the pre tags is the actor provided password, which the webshell uses as a key to decrypt the embedded payload The actor provided password of NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a has the hardcoded salt string aqB2nU65TgFoEfdVqiAddBQLInc9 appended to it The resulting string of NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7aaqB2nU65TgFoEfdVqiAddBQLInc9 has a SHA1 hash of 9d3ff106fbc3508b8453c7d6f285543d0b9c2721, which is base64 encoded to nT/xBvvDUIuEU8fW8oVUPQucJyE= The hardcoded base64 encoded password within the sample is nT/xBvvDUIuEU8fW8oVUPQucJyE=, which confirms that the string provided in the pre tags is the password Once authenticated, the TwoFace++ loader uses the password to decrypt the embedded webshell To use the password as a key for 3DES, TwoFace++ will generate the SHA256 password of the NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a string that results in a hash of 11f66b55f3d24303621e5ef9565b02a576cc58bc5f8789cae96c3d400064b90e The key EfZrVfPSQwNiHl75VlsCpXbM is used as the key for 3DES, which results in a webshell (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) that matches the TwoFace payload webshell we published in our original blog This resulting webshell also appears to be a variant of HighShell, specifically version v5.0 We compared the v5.0 version of HighShell to the TwoFace payload (SHA256: 54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f), as they are visually extremely similar Figure 10 shows the two webshells sharing the same user interface, with two notable exceptions in the HighShell webshell, specifically a version number “v5.0” and three little boxes at the bottom left used to display error messages and the results of commands Figure 10 Animation showing the differences between the HighShell v5.0 and TwoFace payload To supplement the visual similarities, we performed an analysis of the code of the two webshells to identify overlaps The two webshells share a significant amount of code with a majority of the differences being slightly different variable and function names The most notable difference is that the HighShell v5.0 webshell includes a salt value it applies to the actor provided password that it uses for authentication Figure 11 shows the code comparison between the TwoFace payload on the left (SHA256: 54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f) and HighShell v5.0 on the right (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) Figure 11 Comparison between HighShell v5.0 and TwoFace payload The code comparison in Figure 11 also highlights how much code is shared between the two samples We believe the TwoFace payload is a predecessor to the HighShell v5.0 webshell, the latter of which was created during the ongoing development efforts carried out by OilRig throughout their operations HighShell The data dump also included a webshell named HighShell, which we discovered was dropped by HyperShell as discussed in the previous section The dump included many different HighShell samples, of which we have identified at least three different versions, seen in Table 4 The increasing version numbers suggest that OilRig continually developed HighShell to be used in their operations SHA256 Filename Version   fe9cdef3c88f83b74512ec6400b7231d7295bda78079b116627c4bc9b7a373e0 error4.aspx v5.0   22c4023c8daa57434ef79b838e601d9d72833fec363340536396fe7d08ee2017 HighShell.aspx v7.1   691801e3583991a92a2ad7dfa8a85396a97acdf8a0054f3edffd94fc1ad58948 HighShellLocal.aspx 8.6.2    Table 4 Three HighShell webshells within data leak that specified their version The version numbers themselves do not appear to be consistently updated, however For instance, the HighShell webshell (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) extracted from HyperShell in the prior section showed a version number of “v5.0”, which is obviously different than the “v5.0” HighShell with a filename of error4.aspx seen in Figure 12 Figure 12 HighShell v5.0 with a new color scheme and explorer tab Figure 12 shows a second HighShell v5.0 sample with a different color scheme used for its user interface; however, a majority of the functionality is the same as the other v5.0 sample extracted from HyperShell One interesting addition to this variant of HighShell v5.0 is the introduction of a tabular interface that includes a main tab and an explorer tab The main tab contains the same functionality as the TwoFace payload and the other v5.0 HighShell sample The explorer tab, as seen in Figure 13 allows the actors to navigate the compromised server’s file system Figure 13 Figure 14 shows HighShell v7.1 and its multiple tabs Figure 14 HighShell v7.1 spreads out the webshell by using separate tabs for the various functionality The data dump also included an archive named ShellLocal-v8.8.5.rar that contains another HighShell variant The archive name would suggest the HighShell variant was version v8.8.5, but the user interface suggested it was version 8.6.2, as seen in Figure 15 This variant of HighShell shares code from its predecessors, but it appears that OilRig re-architected this webshell to include a front end user interface that interacts with a back end script via AJAX web requests In addition to the change in architecture, this version of HighShell has an enhanced interface as well Figure 15 HighShell v8.6.2 with updated interface The 8.6.2 version of HighShell shares significant functionality with its predecessors, but also contains several new and interesting functionalities as well The interesting features of this version of HighShell includes several executable modules, a network downloader functionality, and a spy check feature Modules HighShell 8.6.2 includes the ability to use several modules included with the webshell The modules are PE executables that come prepackaged with the webshell that further extend its capabilities Table 5 shows the modules provided with this variant of HighShell The webshell will use the 7za module to archive files from the Explorer tab, while the nbtscan module allows the webshell to scan the network for systems to build an IP list of system it can interact with We were unable to determine how the webshell would use the remote execute module, as the webshell does not actually seem to use it Modules included with HighShell v8.6.2 Spy Check The Spy Check functionality appears at the top right corner of the webshell as a box with a countdown timer The timer starts at 300 and decrements every second, suggesting that the webshell executes the Spy Check functionality every five minutes The Spy Check functionality is rather interesting, as we do not know its exact purpose other than either displaying a red box with a spy icon or a green box with a heart icon We believe this functionality was meant to notify the actor in the event that they were using an altered HighShell front end webshell, possibly to avoid using the webshell if it had been detected and modified by a third-party We are speculating this is the intended function because the Spy Check function begins by reading the .aspx file of the HighShell front end (HighShellLocal.aspx in this case) The Spy Check then generates the SHA256 hash of the HighShell front end and compares it with a hardcoded SHA256 of f35e566e28be5b3257670be6e125eb90814b9cb27df997090cea0b7a22fbd75c to determine if the webshell had been modified If the hashes do not match, the webshell will display a red box with spy icon, as seen in Figure 15, or a green box with a heart icon if it matches All known samples display the red box with a spy icon, suggesting that the developer of HighShell did not update this functionality during development efforts or that the samples have been modified in some way To use this functionality, the actor must provide information within the “Target Computer” portion of the webshell, specifically a network administrator username and password, as well as a list of IP addresses of remote systems added in the “Select Computer” drop down Before performing the network download, the webshell checks the storage volume on the server that the webshell is running on to determine if it has more than 30 GB of free space If the server has less than 30 GB of free space the webshell will not perform the activity, which indicates that the developer of the webshell expects a high volume of data downloaded from the victim network Minion Minion appears to be another webshell related to HighShell, as it contains similar functionality and significant code overlap Based on the login functionality within Minion, we believe the same entities were involved in the development of Minion and HyperShell To use Minion, the actor must provide the username of admin and a password to authenticate before using the webshell To authenticate, the password has the string O%tG7Hz57kvWk35$D*)s$1l$pUpLnBw)apHR!xYZWZu7X#^w7$mCArmQMAa&sRBG appended to it as a salt value The webshell generates the SHA256 hash of the resulting string and base64 encodes it to compare with the hardcoded string of m6m8CCWa/u820mie8bX3HKIx1+WQkB+lbmniyXWKB+8= The password and salt string must result in a SHA256 hash of 9ba9bc08259afeef36d2689ef1b5f71ca231d7e590901fa56e69e2c9758a07ef to properly authenticate This is the exact same process used to authenticate/decrypt within HyperShell Much like HighShell version 8.6.2, Minion includes modules to extend the webshell’s functionality Table 6 shows the modules included with Minion, three of which are the same exact files as seen in the HighShell and Minion including Hobocopy and a port scanning, screenshot tool called Tardigrade Can perform port scanning, screenshots and connect to remote systems with “net use” Table 6 Modules included with the Minion webshell DNS Hijacking Script In November 2018, Cisco Talos published research on an attack campaign named DNSpionage It involved attacks using malware to compromise individual endpoints, but most interestingly described an effort to specifically hijack DNS entries of government organizations to redirect visitors to likely malicious, adversary operated systems Both FireEye and Crowdstrike followed up with their own assessments for the DNS hijacking efforts, and described operations extending back to January 2017 No attribution to any known adversary groups was provided, other than that the target radius was primarily in the Middle East and the adversary was also likely operating out of that region In this data dump, a tool called webmask is included which appears to be a series of scripts specifically meant to perform DNS hijacking An informational document is included titled guide.txt, as seen in Figure 16 that provides instructions to the operator on how to execute the DNS hijacking attack using the provided tools Figure 16 Analysis of this IP provides several interesting data points, including possible relationships to previously observed OilRig infrastructure Examining the hosting provider shows that the IP is associated with an Iranian hosting provider called NovinVPS In fact, examining the Class C IP block of 185.162.235[.]0/24 shows at least two other IPs we have previously identified as in use by the OilRig group for C2 servers 185.162.235[.]29 and 185.162.235[.]121 and their associated domains, office365-management[.]com and msoffice-cdn[.]com respectively Office365-management[.]com was first identified in October 2017 as a C2 servers for OilRig operations delivering the ISMInjector backdoor Later in February 2018 we were able to link the entire grouping of infrastructure to another campaign delivering the OopsIE backdoor via the reuse of WHOIS registrant artifacts, shared SSL certificates, and a shared Class C IP block Figure 17 shows the relationship between the files related to DNS hijacking and known infrastructure associated with OilRig Figure 17 Relationship between DNS Hijacking files and OilRig infrastructure Although we are unable to say with certainty that the DNSpionage operations were absolutely executed by the OilRig group, it is possible based on the provided data that there may be some level of relationship between them The screenshot in Figure 18 appears to be a C2 panel for an unknown backdoor The only name provided is Scarecrow, which is not a name we have previously observed or associated with OilRig The server is hosted on 142.234.157[.]21 which appears to be hosted by LeaseWeb If we are to assume the filename is consistent with a real time snapshot of the server panel, it would indicate that multiple systems were actively compromised as of March 29, 2019 Figure 18 Screenshot provided in leak showing Scarecrow panel Figure 19 shows an administrative panel to an Iranian based virtual hosting provider called Berbid Server No other infrastructure details are displayed Figure 19 One of these virtual servers was hosted at an IP address of 193.111.152[.]13 and had been up for 194 days (in the red box in Figure 20) at the time this control panel was apparently accessed Figure 20 This suggests that the server displayed in the VPS control panel may have indeed been in use by the OilRig threat actors at the time of attack In addition, two of the other IPs listed in this panel, 185.161.209[.]57 and 185.161.210[.]25 are in the same 185.161.208[.]0/22 range as an IP associated with the DNSpionage campaign, 185.161.211[.]72 This is a tenuous relationship at best and does not indicate that the OilRig group is the one executing the DNSpionage campaign, but with the combination of the use of DeltaHost and IPs belonging to a fairly small range, there may be reason to believe that these are related to some extent Figure 21 is a screenshot of a C2 server panel for Glimpse, which we track using the name BONDUPDATER If we again assume the accuracy of the time indicated in the filename, this would indicate that no compromised system had checked in since as far out as 71 days Figure 21 Screenshot in leak of RDP session with a server running the Glimpse C2  Conclusion This data dump has provided a rare and unusual perspective into the behind-the-scenes activity in an adversary’s operations It is important to understand that although we are able to validate the backdoors and webshells provided in the dataset as consistent with previously researched OilRig toolsets, in general we are unable to validate the origins of the entirety of the dataset and cannot confirm nor deny that the data has not been manipulated in some manner It is certainly possible that the data dump did indeed originate from a whistleblower, but it is just as likely that a third party was able to extract this data Looking at the data dump as a whole though, the targeting and TTPs are consistent with behaviors we have generally associated with OilRig in the past Assuming the data in the dump is accurate, it also shows the global reach of the OilRig threat group, which generally is assumed to operate primarily in the Middle East The disparity in regions and industries for organizations potentially affected or compromised by OilRig is an excellent example of why organizations regardless of region or industry should always maintain situational awareness of adversaries, their activities, and be prepared to defend against any attack Indicators of Compromise Domains  Myleftheart[.]com office365-management[.]com msoffice-cdn[.]com  Poison Frog PS1 files  27e03b98ae0f6f2650f378e9292384f1350f95ee4f3ac009e0113a8d9e2e14ed 995ea68dcf27c4a2d482b3afadbd8da546d635d72f6b458557175e0cb98dd999 0f20995d431abce885b8bd7dec1013cc1ef7c73886029c67df53101ea330436c  IPs  185.36.191[.]31 185.161.209[.]57 185.161.210[.]25 164.132.67[.]216 212.32.226[.]245 142.234.157[.]21 193.111.152[.]13 185.162.235[.]106 185.162.235[.]29 185.162.235[.]121  OopsIE payload 5f42deb792d8d6f347c58ddbf634a673b3e870ed9977fdd88760e38088cd7336
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 After first uncovering the OilRig group in May 2016, Unit 42 has continued to monitor, observe, and track their activities and evolution over time Since then, OilRig has been heavily researched by the rest of the industry and has been given additional names such as APT34 and Helix Kitten The OilRig group is not particularly sophisticated but is extremely persistent in the pursuit of their mission objective and, unlike other some other espionage motivated adversaries, are much more willing to deviate from their existing attack methodologies and use novel techniques to accomplish their objectives Over time, through our research we have been able to reveal specific details of how their attacks are executed, the tools they use, and even what their development cycle may be like by tracking their use of VirusTotal as a detection check system Due to the nature of the data we had access to however, our perspective was primarily from a target or victim perspective which is generally limited to the artifacts at the time of attack Recently, a data dump was leaked and made available to the public claiming to be data in relation to OilRig activity from the operations side We retrieved the data dump, which included credential dumps, backdoors, webshells, and other files of interest Several media outlets and other researchers have since performed their own evaluation, and in our assessment, we found the artifacts contained in data dump are indeed consistent with known OilRig operations and toolsets In addition, the data dump allowed us to retroactively compare our previous research with OilRig’s operational data This allowed us to fill in previously existing gaps of OilRig’s attack life cycle in addition to validating the accuracy of our research By analyzing the data dump, we have been able to identify exactly how the BONDUPDATER backdoor and its server component functions, the appearance and functionality of several webshells in deployment by OilRig, each of these tools’ internal operational names, and a better understanding of how widespread the OilRig operations may actually be from a global perspective The organizations possibly under attack by OilRig is widely-spread across the spectrum of industry verticals, spanning from government, media, energy, transportation and logistics, and technology service providers In total we identified nearly 13,000 stolen credentials, over 100 deployed webshells, and roughly a dozen backdoor sessions into compromised hosts across 27 countries, 97 organizations, and 18 industries The initial claim included several screenshots of systems potentially in use by OilRig operators for attacks, a script that appeared to be used for DNS hijacking, and a password protected archive with the filename Glimpse.rar purporting to contain the command and control server panel for an OilRig backdoor Soon after, a Twitter account with the user handle @dookhtegan appeared claiming they also had access to data dumps involving internal tools and data used by the OilRig group, as seen in Figure 1 This account used an image from 2004 of a high-profile Iranian asylum seeker named Mehdy Kavousi who famously sewed his eyes and mouth shut to signify that rejecting his asylum claim and sending him back to Iran would be akin to putting him to death It is unknown why this specific image was chosen, other than perhaps as a symbol of protest Since the initial account creation, a stylized version of the original has been substituted as the profile image, making it far more difficult to understand who the original individual was Figure 1 Tweets by @dookhtegan providing files associated with the OilRig leak This account continued a series of tweets voicing protest against the OilRig group and attributing its operations with a specific nation state and organization Unit 42 is unable to validate this level of attribution, but a 2018 report from the United States National Counterintelligence and Security Center stated the OilRig group originates from an Iranian nexus The account continued to post tweets with direct links to operational data dumps hosted on an anonymous file sharing service The files posted included the previously password protected archive Glimpse.rar, as well as new archives containing hundreds of harvested credentials from compromised organizations along with details on exposed login prompts There were also links to webshells previously and possibly currently deployed,  the webshell source codes, as well as another backdoor and its server component This account mirrors the previous messages of exposing the OilRig group but no longer contains links to data dumps, instead instructing those that are interested in the data to join them in a private Telegram channel Figure 2 shows this second Twitter account providing a Telegram channel to leak the data Figure 2 The affected organizations spread across the spectrum of industry verticals, spanning from government, media, energy, transportation and logistics, and technology service providers While we are unable to confirm the validity of the documents detailing individual operators simply due to a lack of visibility into that realm, we also have no reason to doubt their validity either An interesting artifact we found in the data dump are the OilRig threat actors’ own internal names of various tools we have been tracking Table 1 provides the internal operational names and the names we use to track these tools Tools exposed in the OilRig data leak with their internal names mapped to the names used by the security community Credential Dumps In our analysis, we found that a total of fifteen organizations had their credentials stolen in some fashion and stored in text files for the OilRig group to then abuse for additional attacks The types of organizations listed in this data dump spread across multiple industry verticals but were all largely located in the Middle East region This type of activity becomes significantly harder to detect compared to using custom tools as the adversary masquerades as a legitimate user while most protections are intended to catch malware In our past research, based off artifacts we had gathered, we had internally postulated the OilRig group likely had a propensity to immediately attempt to escalate privileges once they have their initial compromise, then try to move laterally into the local Microsoft Exchange server where they would then able to harvest more credentials and implant additional tools such as webshells and IIS backdoors In a presentation provided by a FireEye researcher, they documented this exact attack lifecycle for incidents associated with OilRig in addition to be deploying a post-exploitation toolkit called Ruler within their attack playbook as well Ruler is an open-source penetration testing toolkit which is predicated on being able to access Outlook Web Access (OWA) or OWA via stolen credentials, then abusing built-in functions to perform a variety of actions including retrieving the Global Address List, setting malicious email rules, and in OilRig’s case, performing remote code execution The specific function of Ruler the OilRig group was using is the Ruler.Homepage function This function abuses a capability in Microsoft Outlook which allows an administrator or a user to set a default homepage for any folder inside their inbox Using stolen credentials, the operator would use Ruler to send commands to the target organization’s OWA instance via an RPC protocol which would then remotely set an arbitrary homepage for the compromised inbox’s folders The operator would then include commands in the homepage to automatically retrieve and execute malicious code In OilRig’s case, they included commands to retrieve and execute a backdoor, immediately giving them access to the endpoint in use by the user whose credentials had been stolen Backdoors The data dump included two backdoors that we had previously associated with the OilRig threat group, both of which we had previously referred to as BONDUPDATER Generally speaking, we are able to retrieve the implant or payload involved in an attack but are generally blind to the server side component This data dump provided the backdoors and their associated server components which provides us a different perspective on how the backdoors function In addition, we discovered that the backdoors are actually called Glimpse and Poison Frog internally by OilRig and are functionally two different tools Glimpse The Glimpse tool within the data dump is related to the updated BONDUPDATER tool that we discovered being delivered to a Middle East government organization in a report we published on September 2018 The data dump included the following three requisite components of the Glimpse tool seen in Table 2, as well as a Read me.txt file that explains how to set up and use Glimpse Component Description   Agent Powershell scripts meant to run on compromised systems The three components of the Glimpse tool Glimpse is a PowerShell script that contains the comment version 2.2, which suggests the OilRig group considers this a specific version of the tool and that it likely has included prior versions The Glimpse panel, versioned “v1.0.5” is the tool that the actor uses to organize the various agents installed on compromised systems The panel allows the actors to issue commands in addition to uploading files to and downloading files from the compromised endpoints According to the compilation time, the developer of the Glimpse panel created this tool on September 1, 2018 Figure 3 shows the main Glimpse panel with three different agents listed in a test environment Figure 3 Figure 4 Figure 5 shows the result viewer window showing the results of the issued command Figure 5 The Result Viewer showing the results of an issued command  The server portion of Glimpse works in unison with the panel by acting as a DNS server, which is written in JavaScript and runs in the Node.js runtime The server has a filename of srvr.js, which according to the Read me.txt file is meant to be run using forever start srvr.js in Node.js Figure 6 The Glimpse server issuing a command to an agent and receiving the results of the command Poison Frog The second backdoor included in the data dump is named Poison Frog The dataset includes both the agent that the actor would install on targeted systems and the server that would allow the actor to interact with compromised systems The Poison Frog tool appears to be a variant of BONDUPDATER used in targeted attacks in the Middle East, as reported by FireEye in December 2017 Table 3 shows the files associated with the agent included in the data dump, of which the dUpdater.ps1 portion of Poison Frog appears to be the initial variant of BONDUPDATER that uses DNS tunneling for its C2 channel as discussed in our recent blog discussing OilRig’s DNS tunneling protocols Interestingly, both of these Poison Frog agent scripts were configured to use the domain myleftheart[.]com as its C2 server though we have not seen this domain in any attacks, and we were unable to associate it with any known OilRig infrastructure Files associated with the Poison Frog agent provided in the leak Like the Glimpse C2 server, the Poison Frog server was written in JavaScript and will run in Node.js The headers included in this batch script looked very familiar, as we had seen a very similar batch script provided via the HTTP C2 channel for the Helminth backdoor delivered by a Clayslide delivery document as we reported in October 2016 (SHA256: 903b6d948c16dc92b69fe1de76cf64ab8377893770bf47c29bf91f3fd987f996) Figure 7 The three webshells included in the dump had names HyperShell, HighShell, and Minion, but it appears that Minion is likely a variant of HighShell based on code, filename, and functionality overlaps In addition to the actual webshells in use by OilRig, the data dump includes lists of existing deployments of webshells hosted on compromised websites Over 100 links to webshells are listed, spanning across 87 organizations in 26 countries across four continents as seen in Figure 8 Figure 8 Geographic location of webshells of impacted organizations Hypershell The HyperShell webshell included in the data dump (SHA256: e483eee77fcc5ef11d5bf33a4179312753b62ec9a247dd14528cc797e7632d99) is an example of the 3DES variant of the TwoFace loader that we called TwoFace++ in as we reported in July 2017 The initial TwoFace loader samples decrypted an embedded webshell using an actor provided key, which was modified by using simple arithmetic operators (“+” or “-” specifically) and a salt string embedded within the loader webshell, whose result decrypts an embedded payload using simple arithmetic operators (again, “+” or “-” specifically) Unlike the initial TwoFace loader, the TwoFace++ loader used the 3DES cipher and a SHA256 hash of a string provided by the actor and used as a key, so we were unable to extract the embedded webshells as we were unable to determine the actor provided key However, the HyperShell sample in this dump provided the necessary information to determine the actor-provided key needed to decrypt its embedded webshell Like many initial TwoFace loader samples, the HyperShell sample includes a string within the HTML tags <pre> and </pre> that is displayed in the browser if a password is not supplied and/or the TwoFace++ loader is unable to extract the embedded payload webshell The pre tags within the HyperShell sample are: <pre><%= Server.HtmlEncode(“NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a”) %></pre> Figure 9 shows HyperShell displaying the content within the “pre” tags within the browser Figure 9 HyperShell displaying the password within <pre> tags We determined the string in the pre tags is the actor provided password, which the webshell uses as a key to decrypt the embedded payload The actor provided password of NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a has the hardcoded salt string aqB2nU65TgFoEfdVqiAddBQLInc9 appended to it The resulting string of NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7aaqB2nU65TgFoEfdVqiAddBQLInc9 has a SHA1 hash of 9d3ff106fbc3508b8453c7d6f285543d0b9c2721, which is base64 encoded to nT/xBvvDUIuEU8fW8oVUPQucJyE= The hardcoded base64 encoded password within the sample is nT/xBvvDUIuEU8fW8oVUPQucJyE=, which confirms that the string provided in the pre tags is the password Once authenticated, the TwoFace++ loader uses the password to decrypt the embedded webshell To use the password as a key for 3DES, TwoFace++ will generate the SHA256 password of the NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a string that results in a hash of 11f66b55f3d24303621e5ef9565b02a576cc58bc5f8789cae96c3d400064b90e The key EfZrVfPSQwNiHl75VlsCpXbM is used as the key for 3DES, which results in a webshell (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) that matches the TwoFace payload webshell we published in our original blog This resulting webshell also appears to be a variant of HighShell, specifically version v5.0 We compared the v5.0 version of HighShell to the TwoFace payload (SHA256: 54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f), as they are visually extremely similar Figure 10 shows the two webshells sharing the same user interface, with two notable exceptions in the HighShell webshell, specifically a version number “v5.0” and three little boxes at the bottom left used to display error messages and the results of commands Figure 10 Animation showing the differences between the HighShell v5.0 and TwoFace payload To supplement the visual similarities, we performed an analysis of the code of the two webshells to identify overlaps The two webshells share a significant amount of code with a majority of the differences being slightly different variable and function names The most notable difference is that the HighShell v5.0 webshell includes a salt value it applies to the actor provided password that it uses for authentication Figure 11 shows the code comparison between the TwoFace payload on the left (SHA256: 54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f) and HighShell v5.0 on the right (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) Figure 11 Comparison between HighShell v5.0 and TwoFace payload The code comparison in Figure 11 also highlights how much code is shared between the two samples We believe the TwoFace payload is a predecessor to the HighShell v5.0 webshell, the latter of which was created during the ongoing development efforts carried out by OilRig throughout their operations HighShell The data dump also included a webshell named HighShell, which we discovered was dropped by HyperShell as discussed in the previous section The dump included many different HighShell samples, of which we have identified at least three different versions, seen in Table 4 The increasing version numbers suggest that OilRig continually developed HighShell to be used in their operations SHA256 Filename Version   fe9cdef3c88f83b74512ec6400b7231d7295bda78079b116627c4bc9b7a373e0 error4.aspx v5.0   22c4023c8daa57434ef79b838e601d9d72833fec363340536396fe7d08ee2017 HighShell.aspx v7.1   691801e3583991a92a2ad7dfa8a85396a97acdf8a0054f3edffd94fc1ad58948 HighShellLocal.aspx 8.6.2    Table 4 Three HighShell webshells within data leak that specified their version The version numbers themselves do not appear to be consistently updated, however For instance, the HighShell webshell (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) extracted from HyperShell in the prior section showed a version number of “v5.0”, which is obviously different than the “v5.0” HighShell with a filename of error4.aspx seen in Figure 12 Figure 12 HighShell v5.0 with a new color scheme and explorer tab Figure 12 shows a second HighShell v5.0 sample with a different color scheme used for its user interface; however, a majority of the functionality is the same as the other v5.0 sample extracted from HyperShell One interesting addition to this variant of HighShell v5.0 is the introduction of a tabular interface that includes a main tab and an explorer tab The main tab contains the same functionality as the TwoFace payload and the other v5.0 HighShell sample The explorer tab, as seen in Figure 13 allows the actors to navigate the compromised server’s file system Figure 13 Figure 14 shows HighShell v7.1 and its multiple tabs Figure 14 HighShell v7.1 spreads out the webshell by using separate tabs for the various functionality The data dump also included an archive named ShellLocal-v8.8.5.rar that contains another HighShell variant The archive name would suggest the HighShell variant was version v8.8.5, but the user interface suggested it was version 8.6.2, as seen in Figure 15 This variant of HighShell shares code from its predecessors, but it appears that OilRig re-architected this webshell to include a front end user interface that interacts with a back end script via AJAX web requests In addition to the change in architecture, this version of HighShell has an enhanced interface as well Figure 15 HighShell v8.6.2 with updated interface The 8.6.2 version of HighShell shares significant functionality with its predecessors, but also contains several new and interesting functionalities as well The interesting features of this version of HighShell includes several executable modules, a network downloader functionality, and a spy check feature Modules HighShell 8.6.2 includes the ability to use several modules included with the webshell The modules are PE executables that come prepackaged with the webshell that further extend its capabilities Table 5 shows the modules provided with this variant of HighShell The webshell will use the 7za module to archive files from the Explorer tab, while the nbtscan module allows the webshell to scan the network for systems to build an IP list of system it can interact with We were unable to determine how the webshell would use the remote execute module, as the webshell does not actually seem to use it Modules included with HighShell v8.6.2 Spy Check The Spy Check functionality appears at the top right corner of the webshell as a box with a countdown timer The timer starts at 300 and decrements every second, suggesting that the webshell executes the Spy Check functionality every five minutes The Spy Check functionality is rather interesting, as we do not know its exact purpose other than either displaying a red box with a spy icon or a green box with a heart icon We believe this functionality was meant to notify the actor in the event that they were using an altered HighShell front end webshell, possibly to avoid using the webshell if it had been detected and modified by a third-party We are speculating this is the intended function because the Spy Check function begins by reading the .aspx file of the HighShell front end (HighShellLocal.aspx in this case) The Spy Check then generates the SHA256 hash of the HighShell front end and compares it with a hardcoded SHA256 of f35e566e28be5b3257670be6e125eb90814b9cb27df997090cea0b7a22fbd75c to determine if the webshell had been modified If the hashes do not match, the webshell will display a red box with spy icon, as seen in Figure 15, or a green box with a heart icon if it matches All known samples display the red box with a spy icon, suggesting that the developer of HighShell did not update this functionality during development efforts or that the samples have been modified in some way To use this functionality, the actor must provide information within the “Target Computer” portion of the webshell, specifically a network administrator username and password, as well as a list of IP addresses of remote systems added in the “Select Computer” drop down Before performing the network download, the webshell checks the storage volume on the server that the webshell is running on to determine if it has more than 30 GB of free space If the server has less than 30 GB of free space the webshell will not perform the activity, which indicates that the developer of the webshell expects a high volume of data downloaded from the victim network Minion Minion appears to be another webshell related to HighShell, as it contains similar functionality and significant code overlap Based on the login functionality within Minion, we believe the same entities were involved in the development of Minion and HyperShell To use Minion, the actor must provide the username of admin and a password to authenticate before using the webshell To authenticate, the password has the string O%tG7Hz57kvWk35$D*)s$1l$pUpLnBw)apHR!xYZWZu7X#^w7$mCArmQMAa&sRBG appended to it as a salt value The webshell generates the SHA256 hash of the resulting string and base64 encodes it to compare with the hardcoded string of m6m8CCWa/u820mie8bX3HKIx1+WQkB+lbmniyXWKB+8= The password and salt string must result in a SHA256 hash of 9ba9bc08259afeef36d2689ef1b5f71ca231d7e590901fa56e69e2c9758a07ef to properly authenticate This is the exact same process used to authenticate/decrypt within HyperShell Much like HighShell version 8.6.2, Minion includes modules to extend the webshell’s functionality Table 6 shows the modules included with Minion, three of which are the same exact files as seen in the HighShell and Minion including Hobocopy and a port scanning, screenshot tool called Tardigrade Can perform port scanning, screenshots and connect to remote systems with “net use” Table 6 Modules included with the Minion webshell DNS Hijacking Script In November 2018, Cisco Talos published research on an attack campaign named DNSpionage It involved attacks using malware to compromise individual endpoints, but most interestingly described an effort to specifically hijack DNS entries of government organizations to redirect visitors to likely malicious, adversary operated systems Both FireEye and Crowdstrike followed up with their own assessments for the DNS hijacking efforts, and described operations extending back to January 2017 No attribution to any known adversary groups was provided, other than that the target radius was primarily in the Middle East and the adversary was also likely operating out of that region In this data dump, a tool called webmask is included which appears to be a series of scripts specifically meant to perform DNS hijacking An informational document is included titled guide.txt, as seen in Figure 16 that provides instructions to the operator on how to execute the DNS hijacking attack using the provided tools Figure 16 Analysis of this IP provides several interesting data points, including possible relationships to previously observed OilRig infrastructure Examining the hosting provider shows that the IP is associated with an Iranian hosting provider called NovinVPS In fact, examining the Class C IP block of 185.162.235[.]0/24 shows at least two other IPs we have previously identified as in use by the OilRig group for C2 servers 185.162.235[.]29 and 185.162.235[.]121 and their associated domains, office365-management[.]com and msoffice-cdn[.]com respectively Office365-management[.]com was first identified in October 2017 as a C2 servers for OilRig operations delivering the ISMInjector backdoor Later in February 2018 we were able to link the entire grouping of infrastructure to another campaign delivering the OopsIE backdoor via the reuse of WHOIS registrant artifacts, shared SSL certificates, and a shared Class C IP block Figure 17 shows the relationship between the files related to DNS hijacking and known infrastructure associated with OilRig Figure 17 Relationship between DNS Hijacking files and OilRig infrastructure Although we are unable to say with certainty that the DNSpionage operations were absolutely executed by the OilRig group, it is possible based on the provided data that there may be some level of relationship between them The screenshot in Figure 18 appears to be a C2 panel for an unknown backdoor The only name provided is Scarecrow, which is not a name we have previously observed or associated with OilRig The server is hosted on 142.234.157[.]21 which appears to be hosted by LeaseWeb If we are to assume the filename is consistent with a real time snapshot of the server panel, it would indicate that multiple systems were actively compromised as of March 29, 2019 Figure 18 Screenshot provided in leak showing Scarecrow panel Figure 19 shows an administrative panel to an Iranian based virtual hosting provider called Berbid Server No other infrastructure details are displayed Figure 19 One of these virtual servers was hosted at an IP address of 193.111.152[.]13 and had been up for 194 days (in the red box in Figure 20) at the time this control panel was apparently accessed Figure 20 This suggests that the server displayed in the VPS control panel may have indeed been in use by the OilRig threat actors at the time of attack In addition, two of the other IPs listed in this panel, 185.161.209[.]57 and 185.161.210[.]25 are in the same 185.161.208[.]0/22 range as an IP associated with the DNSpionage campaign, 185.161.211[.]72 This is a tenuous relationship at best and does not indicate that the OilRig group is the one executing the DNSpionage campaign, but with the combination of the use of DeltaHost and IPs belonging to a fairly small range, there may be reason to believe that these are related to some extent Figure 21 is a screenshot of a C2 server panel for Glimpse, which we track using the name BONDUPDATER If we again assume the accuracy of the time indicated in the filename, this would indicate that no compromised system had checked in since as far out as 71 days Figure 21 Screenshot in leak of RDP session with a server running the Glimpse C2  Conclusion This data dump has provided a rare and unusual perspective into the behind-the-scenes activity in an adversary’s operations It is important to understand that although we are able to validate the backdoors and webshells provided in the dataset as consistent with previously researched OilRig toolsets, in general we are unable to validate the origins of the entirety of the dataset and cannot confirm nor deny that the data has not been manipulated in some manner It is certainly possible that the data dump did indeed originate from a whistleblower, but it is just as likely that a third party was able to extract this data Looking at the data dump as a whole though, the targeting and TTPs are consistent with behaviors we have generally associated with OilRig in the past Assuming the data in the dump is accurate, it also shows the global reach of the OilRig threat group, which generally is assumed to operate primarily in the Middle East The disparity in regions and industries for organizations potentially affected or compromised by OilRig is an excellent example of why organizations regardless of region or industry should always maintain situational awareness of adversaries, their activities, and be prepared to defend against any attack Indicators of Compromise Domains  Myleftheart[.]com office365-management[.]com msoffice-cdn[.]com  Poison Frog PS1 files  27e03b98ae0f6f2650f378e9292384f1350f95ee4f3ac009e0113a8d9e2e14ed 995ea68dcf27c4a2d482b3afadbd8da546d635d72f6b458557175e0cb98dd999 0f20995d431abce885b8bd7dec1013cc1ef7c73886029c67df53101ea330436c  IPs  185.36.191[.]31 185.161.209[.]57 185.161.210[.]25 164.132.67[.]216 212.32.226[.]245 142.234.157[.]21 193.111.152[.]13 185.162.235[.]106 185.162.235[.]29 185.162.235[.]121  OopsIE payload 5f42deb792d8d6f347c58ddbf634a673b3e870ed9977fdd88760e38088cd7336 ### Response: .